Data Reporting, Analysis and Corrective Action System (DRACAS)

Printer-friendly versionPrinter-friendly versionPDF versionPDF version

1.1. Data Reporting, Analysis and Corrective Action System (DRACAS)

1.1.1. Description and Purpose

1.1.1.1.

The Data Reporting, Analysis and Corrective Action System (DRACAS) is a closed loop data system for reporting and analysis, used to record information about incidents and corrective actions that have been implemented. The system is intended to provide confidence in the accuracy of the claimed theoretical analysis and correct operation of the safety features.

1.1.1.2.

DRACAS is a necessary part of any good management system that aims for continual improvement by tracking and resolving reported problems. The safety aspect of DRACAS relates to the elimination of failures and deficiencies which impact on safety and DRACAS can be a major contributor to achieving in-service safety.

1.1.1.3.

Over time, the scope of the closed-loop reporting has expanded from Failures to Faults (both abbreviated to FRACAS) to Defects and finally Data (DRACAS). This is in recognition that learning opportunities to improve the system, including its Safety, encompass near misses, human errors and other incidents as well as equipment malfunctions.

1.1.1.4.

The DRACAS should provide traceability of incident management from initial discovery to resolution, or until associated risks have been reduced to a tolerable level. DRACAS should cover all non-conformances and failures relating to design, manufacturing, use, maintenance and test processes that occur during any project activity. Operational and usage data, together with operating conditions should also be recorded to allow event frequency rates to be estimated.

1.1.1.5.

DRACAS provides for reporting of suspected failures and non-conformances as well as observed failures, failure indications and non-conformances. Examples of inputs are incidents resulting from component failures, human error, etc., whether or not they cause harm.

1.1.1.6.

To provide effective management of non-conformances and failures, there should be provision in the DRACAS to ensure that effective action is taken promptly. The DRACAS should be audited to review all active reports, the failure and incident analyses, and corrective action deadlines.

1.1.2. When It Might be Used

1.1.2.1.

DRACAS should be established and maintained throughout the design, development, production and in-service phases of a project life cycle/contract. The safety programme plan should document the requirement for DRACAS, either as a stand-alone activity or as part a Repair and Maintenance programme.

1.1.2.2.

All incidents and corrective actions recorded in DRACAS should be reviewed by a competent Project Safety Engineer. If a new hazard is identified, or there is an amendment to the Risk Classification of an accident, the output from DRACAS must be fed into the Hazard Log. Information from and the use of DRACAS, along with a comprehensive test programme can provide evidence for safety verification.

1.1.3. Advantages, Disadvantages, and Limitations to The Defence Sector or The Particular Domain

1.1.3.1.

Advantages

  • DRACAS encompasses all aspects of development tests, trials and in-service usage.
  • The use of DRACAS from early in a project will aid design, identify corrective actions and help evaluate test results to improve Safety Performance.
  • Use of DRACAS aids elimination of failures and deficiencies, therefore supporting achievement of Safety Growth.

1.1.3.2.

Disadvantages

  • Data collection is only as good as the information fed back. Too complicated or detailed a request for information may result in DRACAS being perceived as being too onerous by the “reporter” and hence the system may not be fully utilised. This could give rise to a false sense of security.
  • Data information and analysis should be managed by personnel who have the appropriate level of knowledge and experience.

 

1.1.4. Sources of Additional Information

1.1.4.1.

A list of additional information (e.g., Standards, textbooks, and websites) includes but is not limited to:

 

 

 

1.1.4.2.

DRACAS Process

1.1.5. Example of a DRACAS Process

1.1.5.1.

The example of a DRACAS process shows how an incident is managed, from the initial reporting of the incident to inclusion of the relevant information in the DRACAS database. The development and structure of the database is important in the successful application of a DRACAS. The need for tracking of incidents, comparison, providing historical evidence etc, means that a bespoke database may be preferable for certain usages. Examples of Software applications are contained in Section 1.4.

1.2. Version Control

1.2.1. Version 2.3 to 3.0 Uplift

1.2.1.1.

Version 2.3 to 3.0 Uplift

Major uplift from the Acquisition System Guidance (ASG) to online version. 

More like this