P T C .

c o m

White Paper

Relex A PTC InSight Product

Page 1 of 7

Organizational Best Practices for FRACAS

Implementation: Management Considerations when
Developing and Deploying a Corrective Action System
Introduction
To produce high quality products in an increasingly competitive marketplace, the ability to efficiently discover,
track, and correct incidents or failures found during product development, testing, and operations is crucial. This
need spans all industries and classifications, including hardware and software production, process management,
and services in both government and commercial sectors. A survey conducted by the Reliability Information
Analysis Center (RiAC) cited that companies view this subject, most commonly referred to as FRACAS (Failure
Reporting, Analysis, and Corrective Action System) to be among their top two most important reliability tasks.
Manufacturers and service providers have employed a variety of methods for tracking product failures and managing corrective actions. These can range from so-called manual approaches using paper-based intake methods
and handwritten forms, to a combination of electronic spreadsheets and personal databases, to large enterprise
systems that affect hundreds or thousands of customers, suppliers, and engineers worldwide. Conceptually, it
is easy to understand the need for and the benefits of a failure tracking and corrective action system. However,
implementing an efficient and effective system that yields an end result of more reliable products and improved
designs is complex. A wide range of factors must be considered by organizational management and those responsible for directing and implementing the FRACAS company-wide to ensure the best possible outcome.
Since its inception in the 1970s as part of the United States Department of Defense (DoD) regulations, efforts
have been made to define structured approaches and guidelines for the implementation of failure reporting,
analysis and corrective action systems. Organizations such as RiAC, in accordance with the DoD, have studied the
requirements of both large and small companies to develop general guidelines for a FRACAS. In addition to the
RiAC guidelines, other efforts on this subject have been published for public use, including SEMATECHs Failure
Reporting, Analysis and Corrective Action System Planning and Implementation Guide and NASAs Preferred
Reliability Practices, Problem Reporting and Corrective Action System documents.
Nevertheless, the implementation of a cost-effective FRACAS that produces an end result of more reliable products
remains a complex and challenging undertaking. These publicly available guidelines fail to address many of the
practical complications that exist. These complications are neither process-related nor technical in nature, but
stem from each companys organizational structure, goals, and expectations.

White Paper

Relex A PTC InSight Product

Page 2 of 7

1. What is a FRACAS?
A FRACAS, or Failure Reporting, Analysis, and Corrective Action
System, is a closed loop system used to improve the reliability of a
product, service, process, or software application. The closed loop
in a FRACAS refers to the systematic manner in which every issue
that is reported is addressed, ensuring that no failure or incident is
missed. The need for a FRACAS spans all industries and classifications,
including hardware, software, process management, and services in
both government and commercial sectors. Software-based FRACAS
processes offer the added benefit of built-in analytical capabilities,
allowing organizations to track key system metrics that include Failure
Rate, MTBF, MTTR, Availability, Cost, and user-defined calculations,
among many others. Built-in reporting and graphing features mean
these metrics to can be trended with regards to time, severity, and
many other factors. In addition, the effectiveness of the FRACAS itself
can be monitored by tracking the overall improvement of the system
as a result of the FRACAS.
FRACAS is used extensively in the following industries: Aerospace,
Automotive, Defense, Electronics, Manufacturing, Telecommunications,
Medical Devices, and others. While a corrective action system is commonly referred to as a FRACAS in many government-related initiatives,
it may be referred to by other names in other industries, including
a CAPA (Corrective and Preventive Action) System, Corrective Action
System, Quality System, and others where the first letter of the FRACAS
acronym is replaced by a P for Problem (PRACAS), an I for Incident
(IRACAS), or a D for Data or Defect (DRACAS). In addition, FRACAS
can be applied for RMA (Return Materials Authorization or Return
Merchandise Authorization) processes and various other quality assurance processes, like bug tracking, call centers, and the like.
How is a FRACAS Performed?

While the specifics of how each FRACAS process is implemented will

vary, a FRACAS usually includes the following steps:
Record the Failures or Incidents: Using a database management
system and an established procedure, critical data associated with
each failure or incident is recorded, and the process is initiated
Analyze the Reported Failures or Incidents: Using the same
database management system into which the failure or incident
data was entered, established procedures are used to determine
and record the root cause of the failure or incident
Identify Necessary Corrective Action: Using the same database
management system to track its development, implementation,
and result, a corrective action plan must be developed and
implemented to reduce or eliminate the reoccurrence of the
failure or incident
Review and Verify the Corrective Action: The effectiveness of
the corrective action must be reviewed and recorded, using the
same database management system, and the incident closed out
per established procedures

An effective FRACAS ensures that all failures or incidents proceed through these
four major steps: closing the loop to ensure that no failure or incident is missed.

What are the Limitations of a FRACAS?

Although implementing a FRACAS can be an excellent way to improve

a product, service, or process, its inherent limitation is that it can be
difficult to apply effectively. As with any technique, it is critical that a
FRACAS process is well planned and efficiently executed; otherwise, the
system could fail to manage data effectively, fail to identify the root
causes of problems, or fail to close the loop in the FRACAS process.
For that reason, the Relex team, which has deployed numerous FRACAS
systems in organizations throughout a variety of industries, presents the
following practical guidelines for managers and others responsible for
the development and implementation of a successful FRACAS system.

2. FRACAS Best Practices

While the general closed loop corrective action process seems to follow
a common sense approach, many factors can make the application of
a FRACAS difficult. Because of these potential challenges, the following best practices are strongly recommended for use during FRACAS
implementations.
Set Expectations and Goals

Prior to deploying the FRACAS corrective action system, it is essential

to set the expectations and goals of the system. Identifying the purpose
and goals of the FRACAS, as well as identifying the roles and responsibilities of all stakeholders in the process, is essential. It is also critical
that all stakeholders in the process understand and agree upon the
established expectations and goals of the system.
Involve the Stakeholders

It is of the utmost importance that all stakeholders in the FRACAS

are involved in and supportive of the process. The stakeholders will
include many within the organization and may also include customers
and/or suppliers. By involving all stakeholders, support may be gained
for acquiring sufficient failure data, and a common process can be
achieved across the whole organization and outside entities.

White Paper

Relex A PTC InSight Product

Page 3 of 7

A survey conducted by the Reliability Information Analysis Center (RiAC) cited that companies view a
FRACAS to be among their top two most important reliability tasks.

Gain Active Management Involvement

Management involvement and support can significantly impact the

success of the FRACAS. Active management participation often results
in obtaining and maintaining necessary funding and resources, and
may very well provide the leadership needed to implement and maintain a successful FRACAS.
Keep the Process Simple

The most successful FRACAS processes are easy to use, employ userfriendly software tools to automate the workflow, and require modest investments in resources and training. By keeping things simple, it
is more likely that those outside the quality/reliability functions will
participate as required. Ultimately, it is important that the FRACAS be
simple enough to work well for both the expert and novice. Of course,
it is also important that the process is designed to allow for a thorough
and effective FRACAS.

3. Apply Best Practices to Common Challenges

The best way to observe the benefits of these best practice approaches
is to see the ways in which they help overcome the challenges that organizations commonly experience when implementing a FRACAS. Each of
the following Challenge / Solution scenarios demonstrates the benefits
of a best practice approach to FRACAS implementation:
Challenge 1: Complex Organizational Interactions

A proper FRACAS process can span many different functional groups

within an organization. Data is contributed by and/or needs to be made
available to the following groups:
Manufacturing

Quality Assurance

Operations

Customer Service

Reliability

Field Services

Sales and Marketing

Suppliers

Leverage Software Tools

Testing

Maintenance

Utilizing available software tools is one key way to help automate the
FRACAS and make it easier to use. Software tools can help automate
data entry, data analysis, and data output, while providing a central
storage area for critical FRACAS data and results.

Failure Review Board (FRB)

Management

Engineering

Others

Provide for Efficient Data Entry and Analysis

The collection and analysis of FRACAS data can be two of the most
time-consuming tasks for a FRACAS. Easy to use Web-based forms are
often a great way to provide for efficient data entry. Automated calculations, graphs, and reports, along with the ability to filter data, can
increase the efficiency and effectiveness of data analysis.
Supply Training

Even when a simple FRACAS process is implemented, providing comprehensive training early in the implementation process can alleviate
the concerns of those involved and help make them active participants
in the FRACAS. As feedback is accepted and the FRACAS evolves, it is a
good idea to provide additional training in the more advanced technical and software-related aspects of the process.
Encourage and Offer Feedback

Encouraging feedback from the users of the FRACAS can help those
in leadership roles adjust the FRACAS to become more efficient and
effective. Likewise, providing feedback to all participants, including
feedback in the form of outputs from the system, can be encouraging,
as it can demonstrate the positive, tangible results of the efforts of all
who have adapted to and successfully implemented the FRACAS.

With all of these different groups involved in the process, the interaction across and between various groups can become quite complex.
Some groups may need to be included at multiple points throughout
the workflow. This increases and complicates the steps required to close
out an incident. Consider the following scenario: A simple process is
defined such that a field service representative reports or logs an incident. Quality Assurance reviews this incident and then assigns it to
the Reliability group to perform a root cause analysis. The Reliability
group then recommends a corrective action that the Engineering group
implements. Finally, the Failure Review Board approves the corrective
action and closes out the incident.
Over time, additional groups may request to be involved. For example,
Customer Service believes that they too need to be involved at the corrective action step in the process. Because they directly interface with
the customer, they want to understand and possibly shape the corrective action response that may occur. Sales and Marketing may also
need to be involved to properly manage a customers account. And, a
Supplier may wish to be involved in the analysis and corrective actions
that have occurred with its parts. Very quickly, the number of groups
involved increases, and the process becomes more complex. This may
result in a long cycle time between the opening of an incident and its
eventual closing. If the process is too complex, incidents can become
forgotten and never worked through to completion.

White Paper

Relex A PTC InSight Product

Page 4 of 7

Solution 1: Overcoming the Challenge of Complex Interactions

While working with the stakeholders in the planning phases of a

FRACAS, identify the simplest workflow possible while still keeping
everyone involved at key steps in the process. Whenever possible, automate communication. This way, all groups that need to be aware of the
status of an incident can be notified easily. It is generally helpful if each
functional group has a key contact person who may attend FRACAS
planning meetings and communicate important information to the
functional group.
Regular FRACAS process review meetings involving all key stakeholders from the various functional groups can be helpful. These meetings
can decrease in frequency over time. And, of course, before the final
FRACAS is deployed, make sure that all stakeholders have signed off on
the proposed communication plans to ensure you can overcome the
challenge of complex organization interaction.
Challenge 2: A Lack of Prioritized Goals

Consider the following scenario: a customer contract specifies that a

FRACAS system be utilized for a particular project. But due to financial constraints, the resources are lacking to complete a fully featured
FRACAS implementation. Project managers implement a temporary
Microsoft Excel-based or Microsoft Access-based solution, fully
intending to replace this solution in the future with a more substantial
system. But a fully featured FRACAS never materializes. Consequently,
a minimal FRACAS system becomes the standard, resulting in poor efficiency and a lack of cohesiveness.

Involving all stakeholders in

the FRACAS workflow: Each
group in an organization has
different roles in the FRACAS.
The goal in designing a
FRACAS is to accurately
capture each groups role
and to ensure that software
processes carry this workflow through to each required
member automatically.
Web-based communication
technology like that found
in Relex FRACAS can help
ensure that every incident is
addressed: effectively "closing the loop".

In another example, a company believes that a FRACAS is important

to the success of a product but sees it as something they will get to in
the future. As the product lifecycle progresses, the company gains an
appreciation for the necessity of a FRACAS. By this time, the company
is far past the point of the budgeting and planning processes. Therefore,
a proper implementation does not occur and teams are left scrambling
late in the project to find resources to implement a FRACAS. Once again,
a minimal FRACAS system is implemented.
In a third example, an executive management team has high expectations for the system. They envision that the FRACAS will save the
company money on warranty costs; while the reliability group expects
significant data that can be used to discover trends and improve a products design over time. Unfortunately, because the program manager is
provided with minimal financial resources, she can only implement a
basic FRACAS. The system is not deployed early enough to sufficiently
track information, which limits the data available to executive management and to the reliability group. It will take some time for the data to
be complete enough to perform a meaningful analysis. The result is a
system that falls short of everyones expectations.
What caused the problems in these examples? First, goals and expectations from the various groups were not discussed and prioritized in relation to each other. Second, there was no objective FRACAS leadership
across the groups. And, finally, effective executive sponsorship verifying
and tracking the goals was nonexistent.

White Paper

Relex A PTC InSight Product

Page 5 of 7

Solution 2: Overcoming a Lack of Prioritized Goals

To overcome the problems that result from the lack

of prioritized goals, use best practice principles. First,
the goals and expectations of the FRACAS should
be discussed and agreed upon by all stakeholders,
including management. It is also helpful to obtain
objective FRACAS leadership so that all stakeholders goals may be considered in the planning. Also,
determine which goals can be accomplished well by
the FRACAS as it has been designed, and make sure
all stakeholders have signed off on and agreed to
these planned and prioritized goals.

Streamlining Data Entry and Data Tracking: By entering a single identifier, such as the serial number of a
returned product, as shown above, Relex FRACAS uses lookup table functionality to autopopulate the remaining fields.

Challenge 3: Ineffective Data Tracking

The key to ensuring a FRACAS is effective is to gather and report meaningful data. This seems to suggest that the more data an organization
can gather regarding an incident or failure, the better its FRACAS will be.
But this is not necessarily the case. Too much data may prevent companies from discovering meaningful trends.
For example, many legacy FRACAS systems collect 80 or more fields of
information when recording a failure. Although much of this data is
valuable, gathering too much data can result in several problems. For
example, suppose it takes customer support personnel five seconds to
enter data into each field. They will spend 400 seconds or 6.6 minutes
filling in all 80 fields, not including research time, resulting in a general
feeling that it is just too time consuming to fully log a problem. Fields
are routinely skipped and some issues are not even reported because it is
too much trouble. To prevent this, designers develop input screens that
will easily accept incident information.
However, as is often done, designers utilize free flowing text fields to
allow customer support personnel to type any information that they
think is useful. The personnel can then become confused, and do not
always know what to enter. Consequently, they begin to include extraneous or irrelevant data and sometimes just leave the field blank. Not
only is it difficult to perform any meaningful analysis with the resulting
data, but it also becomes a tedious manual process to review each individual incident in search of trends.
Solution 3: Effectively Managing Data

To avoid the problems of inefficient and ineffective data tracking, organizations should establish functional procedures before data collection
begins. Using simple, streamlined forms which store data in a central
database is often the best approach. Training the FRACAS users responsible for data entry helps ensure that all important data is entered correctly and efficiently. It is also helpful to remind those responsible for
entering failure data of the importance of capturing the data at the time
of failure, and the long term benefits to the organization that can result
from timely data capture. Whenever possible, employ automation when
capturing the failure data.

4. Steps to a Successful FRACAS

These three common challenges to FRACAS implementations are by
no means all-encompassing, but they do outline typical problems
that prevent companies from realizing the dramatic results that can
be achieved with a successful FRACAS. To help avoid these common
obstacles from the outset of planning a FRACAS, the following eight
steps are recommended:
Step 1: Define the Goals and Success Factors

Defining the goals of all intended users and stakeholders is the foundation for a successful FRACAS. Every step in the process of implementing a FRACAS will be based upon these goals. Ensuring these goals are
understood and agreed upon by all is key before implementing the
FRACAS. A mistake or misunderstanding at this step can have negative consequences later. Because issues may not become known until
months later, it is important to commit to a thorough job of researching
and documenting everyones goals and the rationale behind them.
To begin this process, hold a series of short team meetings with each
of the groups and stakeholders with a role in the FRACAS. Map out
each groups specific goals and expectations for the FRACAS. Typical
goals include lowering maintenance costs, improving overall reliability,
and improving next generation product design. Be careful to avoid the
common pitfall of moving off of goal establishment and into detailed
requirements. The purpose of this exercise is for each group to come to
a consensus on the priority of its primary goals.
Step 2: Define the Output

With goals and success factors in place, it is time to define the results
or outputs that each group is expecting from the FRACAS system to
achieve the success factors that were outlined in the groups agreedupon goals. Typically, the results are stated in terms of calculations,
charts, graphs, and reports. For example, the Reliability group may need
a Pareto chart indicating the number of failures by part number. The
Field Service group may require a report indicating the cost of warranty repairs by part number. The Quality group may require a reliability
growth chart.

White Paper

Relex A PTC InSight Product

Page 6 of 7

A common pitfall is that each group will want as much output

as possible, resulting in a bloated wish list that is difficult to
reasonably implement. The purpose of this exercise, however,
is to focus on what is absolutely necessary for success based
on previously established goals. To help with this, map each
output requirement back to a goal and success factor.
Step 3: Map the Process Workflow

Through a series of meetings and interviews with stakeholders,

discuss what process or workflow they expect to follow. Most of
the groups will focus on their own internal processes but may
not understand the overall process as it relates to all groups
with a role in FRACAS. Based on each groups individual input
and through additional investigation, develop a consolidated
process diagram. Using this diagram, search out inefficiencies
and actively find ways to simplify the process.
Involve stakeholders in simplifying and coordinating the process steps between the groups. Question any step that does not
produce the output requirements established previously. Also,
work to ensure that the overall process is not too lengthy or
complex. Remember that many steps can slow the resolution
of incidents or decrease the ability to report trends in a timely
manner. Changes to the overall process are inevitable, but this
step establishes a workable starting point.

Determine a workflow for the FRACAS: Ensure that roles of all stakeholders involved in
the process are properly represented, as in this RMA (Return Materials Authorization) workflow.

Step 4: Map the Required Data and Input Method

Using the process diagram and the output requirements, determine the
minimum data fields required to support the workflow process at each
step. Investing time in this step helps eliminate the problem of collecting data with no direct purpose, and can help focus users' efforts.
After the data fields have been established, determine how the data will
be viewed by the user. It may make sense to show one large form with
all of the data fields. Or, it may be better for each group to have specific
forms with specific fields displayed so that their view of the data is limited for ease of understanding. Involve the stakeholders to understand
what they are expecting and why.
Additionally, specify how the input data will be gathered. Recall, from
Challenge 3 above, that it is important to collect valid, meaningful
data in an efficient manner. Popular methods include lookup tables to
populate fields based on previous input, drop-down menu choices for
standardized data entry, and bar code scanning.
Step 5: Implement a Prototype FRACAS

Now that the goals, success factors, expected output, workflow process,
and entry forms are defined, you are ready to choose an implementation approach. General purpose tools, such as spreadsheets and personal database programs like Microsoft Excel or Microsoft Access, are
limited in their capacity to handle large amounts of data and may not
support the sharing of data between multiple users. FRACAS calculations and graphing are not intrinsically supported by general purpose
software, and no functionality is included to generate workflow noti-

fications automatically and ensure a closed loop process. In addition,

this approach may require internal support to create and maintain a
customized application.
Based upon the size of the workgroup, a small group collaboration tool
or a large, Enterprise-wide application may be required. Relex FRACAS
offers solutions for both sizes of workgroups, including workflow capabilities, built-in FRACAS calculations, and seamless integration with
other reliability, maintainability, and risk analysis applications to effect
a more detailed analysis. Enterprise applications provide additional
tools for handling large amounts of data, including Web-based tools
for streamlined data entry, workflow alerts delivered via e-mail, support
for Microsoft Active Directory Services, and many simultaneous users.
Relex FRACAS also supports commercial-off-the-shelf (COTS) templates with preconfigured FRACAS workflow steps, making it easy to
start from a predefined solution or configure it in a few easy steps
to suit organizational needs. This solution helps companies avoid the
expensive, time-consuming, and often intractable results of hiring specialized consultants to create a customized solution. Easily configurable templates can be continuously adapted as your FRACAS process
changes and develops, without the need for specialized programming
skills.
Whether selecting a small group collaboration tool or a large, Enterprisewide FRACAS application, examine the organization's immediate needs
in relation to its future plans. It is important to consider the functionality required by your specific FRACAS process, the number of potential
users, and the data storage requirements both at the projects inception
and well into the future. To validate the decision, implement a prototype FRACAS based on the selected approach.

White Paper

Relex A PTC InSight Product

Page 7 of 7

Step 6: Accept Feedback and Modify the FRACAS

Once the prototype FRACAS has been implemented, with sufficient

time for users to test and get a feel for it, it is important to bring the
stakeholders back together and evaluate the results of the prototype
system. Is this environment effective for the previously defined workflow process? Is data entry efficient and streamlined? Can the expected
outputs be generated? Is the system easy to use and understand?
Most importantly, revisit the goals and success factors. Does the system
fulfill these goals? Will the success factors be met? It is very likely that
you will find areas of the system that need to be reworked. This is the
time to accept constructive feedback and make the necessary modifications. Before proceeding, gain signoff and approval from all stakeholders. You will need their continued support to make the implementation
a success.
Step 7: Rollout and Training

Although it may be necessary, when time is of the essence, to allow all

users onto the system at once, this approach is likely to have more issues.
With so many users starting out at the same time, seemingly minor
issues can become major obstacles. Although this approach can work,
it requires significant planning and coordination. It should only be
considered when absolutely necessary. Alternately, a phased approach
whereby several groups at a time are trained and then brought online
is the preferred implementation method. By using this approach, any
unforeseen issues can be addressed without involving the entire user
base. Additionally, the implementation and training teams are able to
adapt to these issues and provide better support for later groups.
Typically, the more individualized attention and training given to users,
the better their acceptance and support of the FRACAS will be. Training
is extremely important, especially when typical FRACAS systems involve
users of many different areas of interest and levels of expertise. When
users understand what is expected of them and are empowered by training to use the FRACAS, the system has a much greater chance for acceptance and success.
Step 8: Continue to Change and Adapt the FRACAS

One of the most important aspects of a FRACAS is to learn what works

and what can be improved. Based on this feedback, continual change
can and should be expected. As business objectives and processes
change, the FRACAS needs to be adapted to support these changes. It
is important, however, that the FRACAS is actively managed to not only
accept these changes but to also validate these changes in relation to
the overall goals that were initially established.

5. Conclusion
Yielding more reliable products, better collaboration throughout teams
in the organization, and valuable system metrics to track product performance over many different factors, an effective FRACAS is a valuable
tool for any company seeking to improve its quality and reputation. By
examining the best practice approaches to implementing a FRACAS
process, companies can help ensure successful adoption, streamlined
implementation, and effective results from the system.

6. About the Authors

Daniel Jacob is an ASQ Certified Reliability Engineer with an extensive
and diverse background in engineering, project management, technical
sales, and market development. As a Relex Regional Account Manager,
Mr. Jacob works with customers to determine the software and processes necessary to meet corporate and program objectives.
Jennifer Akers is an ASQ Certified Reliability Engineer responsible
for all Relex training services. As a Relex Senior Application Engineer
and Curriculum Developer, Jennifer has developed numerous training
courses that focus on both the theoretical foundations and practical
applications of Relex software tools.

7. Bibliography
1. Failure Reporting, Analysis and Corrective Action System
(FRACAS) Application Guidelines, Product Code FRACAS, Reliability
Analysis Center, 1999 Sep., p 5.
2. M. Villacourt, P. Govil, Failure Reporting, Analysis and
Corrective Action System (FRACAS), Doc ID #: 94042332A-GEN,
SEMATECH, 1994 Jun., Available at
http://www.sematech.org/docubase/document/2332agen.pdf
3. NASA, Preferred Reliability Practices Problem Reporting and
Corrective Action System, Practice No. PD-ED-1255, available at
http://klabs.org/DEI/References/design_guidelines/design_
series/1255ksc.pdf
4. MIL-HDBK-2155 Department of Defense Handbook: Failure
Reporting, Analysis and Corrective Actions Taken
5. RiAC: Reliability Problem Solving, Failure Reporting and
Corrective Action System (FRACAS) and Reverse Engineering,
http://src.alionscience.com/pdf/fracas.pdf
6. E.J. Hallquist, T. Schick, Best Practices for a FRACAS
Implementation, pp 663-667, RAMS 2004.
7. J.S. Magnus, Standardized FRACAS for non-standardized products, pp 447-451, RAMS 1989.
8. A. Mukherjee, Integrated FRACAS systems for F117 infrared
acquisition designation system (IRADS) support yield higher
MTBMA, pp 26 - 29, RAMS 2005.
9. MIL-STD-721C: Definitions of Terms for Reliability and
Maintainability, 1981.

8. Learn More
For more information about Relex FRACAS, please visit:
www.relex.com/products/fracas.asp
Copyright 2009, Parametric Technology Corporation (PTC). All rights reserved. Information described
herein is furnished for informational use only, is subject to change without notice, and should not be
construed as a guarantee, commitment, condition or offer by PTC. PTC, the PTC logotype, Relex, and all
PTC product names and logos are trademarks or registered trademarks of PTC and/or its subsidiaries in
the United States and in other countries. All other product or company names are the property of their
respective owners.

4915-Relex-WP-1009