RTK is available for Linux and Windows .
There is no such things as a "one-size fits all" reliability program or process. Every organization needs to have a process that fits best with their corporate culture and their industry. However, there are certain methods and analyses common to all successful reliability programs. RTK supports many of these popular analyses and more functionality is added with every release. Many existing RTK features are discussed on this page or can be seen in the RTK screenshot gallery.
RTK is layed out in three windows. Each of these windows is referred to as a book. There is a Module Book, a Work Book, and a List Book. The Module Book allows the selection of one of the nine RTK modules. Lists and matrices associated with the selected module are found in the List Book. The attributes of the selected item in the Module Book can be viewed and edited in the Work Book. This screenshot shows the layout of these three books before loading a program database.
As mentioned above, RTK consists of modules. A module represents a characteristic of a system or an aspect of the development program. Each module provides a different view of the system under development. RTK consists of nine modules. These nine modules are:
- Verification & Validation
- Program Incidents
- Reliability Testing
- Survival Analysis
Modules are accessed via the RTK Module Book. These modules are discussed in greater detail in the side pane.
Each RTK module has various attributes. The number of attributes, as well as the content of each attribute, varies with each RTK module. Attributes can be anything from the name of a revision, the failure rate of a hardware assembly, or the failure mode of a function.
Attributes are primarily accessed through the RTK Work Book.
There are two methods for navigating through the various modules in RTK. The first method, or the "classical" method, is to select the module to work with in the Module Book. With the module you wish to work with selected in the Module Book, you would select the proper page in the Work Book for the analysis you wish to perform.
The second method of navigating RTK is through the use of a process map. With the process map, a mouse click will take you to the proper module in the Module Book and the appropriate page in the Work Book to perform the analysis. For example, if your reliability process includes a step to gather stakeholder inputs (i.e., Voice of the Customer), clicking on this step in the process map will select the Revision module in the Module Book and the first page in the Work Book.
This screenshot shows RTK being navigated via the process map. However, because no two organizations have exactly the same reliability process, ReliaQual Associates will work with your team to accurately define your process and then create the navigable process map.
Many aspects of RTK are user-configurable. Users have some control over the look and feel of the user interface such as the position of the tabs in the various notebooks. The column headings in the various spreadsheet-type views can be set by the user if the default headings don't meet their needs. For example, the column headings in the FMEA use typical MIL-STD-1629A or automotive terminology. These headings can be changed by the user to reflect the terminology used by their organization. Items in many of the drop down lists can be deleted, edited, or appended by users with administrator credentials.
Customization beyond this can be performed by ReliaQual Associates, LLC. Just contact us with your customization needs and we'll provide a proposal.
The RTK Modules
The Revision module is used to document and analyze different revisions or configurations of a system. For example, a revision could be a model year, a change to an existing system, or a configuration that includes optional features.
The Function module documents and analyzes the functions of a system. Functional analysis is important during conceptual design before hardware details are defined. As the development program progresses and hardware becomes defined, the Function module allows the relationships between hardware assemblies and functions to be visualized.
Requirements for a configuration are documented and analyzed in the Requirements module. Documentation of a revision's requirements begins with the elicitation of stakeholder inputs. Once stakeholder inputs are captured, requirements can be developed and written in engineering terminology. These requirements can then be analyzed for clarity, completeness, consistency, and verifiability. Finally, those tasks that will be used to validate the design can be linked to each requirement.
Analysis of the system hardware is performed in the Hardware module. Available analyses include reliability allocations, hazards analysis, similar item analysis,handbook reliability predictions, and FMEA. The FMEA supports MIL-STD-1629A and automotive style (RPN) criticality analysis.
System software is analyzed to determine program risk for each Software module. Risk is determined by considering the development organization, methods used, documentation of requirements, and tools and test techniques used to develop the software.
Verification & Validation
Verification and validation tasks are those analyses and tests used to verify and validate the design satisfies program requirements. These tasks can be linked to the requirement to be verified and validated in the Requirements module. Within the Verification & Validation module, the overall progress of the validation program is tracked.
Testing is an important aspect of a development program. In the Testing module, various reliability tests can be planned, tracked, and the results assessed. Currently RTK supports reliability growth, reliability demonstration/qualification, and environmental stress screening (ESS) testing.
Regardless of how well a development program proactively addresses reliability, there will always be problems. While ReliaQual Associates recommends a dedicated FRACA application, RTK provides a minimal FRACA system with the Incidents module. The intent of the Incidents module is to provide the Reliability Engineer a view of problems that often are not be available in non-FRACA production systems that capture failure information. Computerized maintenance management systems (CMMS) are one example. Additionally, the Incident module allows the engineer to add information to a failure record that may not be germane to the production system's purpose, but is critical from a reliability perspective.
Estimating the reliability of a system under development can be accomplished in several ways. Field and test data from an earlier version, different configuration, or similar system adjusted as necessary for the new system generally provides a more accurate estimate than handbook prediction methods. After fielding a system, it is important to track the field reliability and adjust maintenance policies or make design changes as needed to address problems or trends. The Survival Analysis module gives the Reliability Engineer the ability to analyze field and test failure data to estimate reliability metrics such as failure rates, MTBF, and reliability. RTK's Survival Analysis module supports analytical methods appropriate for repairable and non-repairable items.