HARA for product

User Modules

Task, project & quality management
Contacts and directories module (CRM)
Web management and automation
Human resources
Products, assets and sales
Finance management
Metrics and Measurements

Technical Modules

Sabre plugin module
Enterprise Architect connector

System Modules

The AyMINE Framework Module
System Management

Give us contact

Do you prefer to ask us directly?

Call us +420 605 203 938 (the Czech Republic)

or use this contacts

HARA for product

Hazard & Risk Analysis is the initial step in the decision-making process to classify a product in the safety class. System support helps you to make and document the analysis and its progress

The results of HARA analysis are crucial for assessing whether a product can be developed in the "normal" quality control mode (QM-level) or must be developed according to one of the ASIL A-D or SIL levels (depending on the type of standard; further, for simplicity, common (A)SIL)


HARA and FMEA both work with similar concepts and product ratings, but their basis is fundamentally different. The fundamental difference between HARA and FMEA is at the time of implementation and the detail of the analysis. In terms of the HARA processing process, it corresponds to the HAZOP (Hazard and operability study) standard.

HARA analysis is performed in a project at the very beginning, when its detailed analysis is not known. The basis of the assessment is therefore its potential operational impacts.

Within HARA analysis, the key question is: What is the risk that may arise from the part under consideration?

FMEA analysis is carried out on the basis of a detailed analysis and is based on the possible failures of the individual components and components that make up the product under consideration.

The key question of FMEA analysis is: What may break down and what may cause it?

For FMEA and HARA, the common point for the analysis is that the assessment is carried out in the context of

  • Assessment of the risks caused. Example: Serious injury risk
  • Risk assessment based on the assessment of how often the conditions occur when the threat may occur. Example: Driving/operating at night

How to carry out HARA analysis

The HARA analysis is described here on the basis of ISO 26262-3. However, the procedure is identical for other standards, e.g. Mil Std 882D.

The basic steps of HARA analysis are

  1. Identification of the product for which HARA analysis is carried out.
  2. Description of the environment in which it is used, especially what is in its surroundings and may be affected by the product
  3. Operational modes in which it is used and the frequency of the given threat
  4. What threats it may cause in each mode
  5. Overall assessment (rating) of the threat given by the product of the threat, the probability of the situation

The result of the analysis is

  • Proposals for measures that reduce threats
  • Classification in ASIL / SIL safety class (Depending on the type of standard used)

Measures must have practical outcomes

Measures must have practical outcomes in order to make sense, they must be translated into specific requirements that the design meets. A typical example of a measure is:


Redundancy is the duplication of an element that may fail.
The most obvious example is car lights, which are duplicated even with much internal logic. Redundancy is used more than it seems at first glance. It is not just flashing lights in the mirror (duplicating the front flashing lights) but e.g. independent sensors, calculating values from other data – e.g. combination of data from other sensors, etc. Duplication is also used for indicators reporting a problem to the driver.

Safety mode

The basis of the safety mode is the recognition of a fault, potential fault or risk of a fault occurring and switching to the safety mode.

An example of a safety mode is a reduction in the power output of an electric car engine when the battery temperature exceeds a specified threshold.

Increase in reliability

Increased reliability means the use of materials, parts and manufacturing processes that are less likely to fail. Reliability is important for all 3 basic parts – HW / SW / ME (hardware, software, mechanical parts).

As banal as it sounds, increasing the reliability of a part is definitely not banal. Examples are

  • For hardware: use of components with higher protection against elmgmt. interference, temperature resistance, etc.
  • For software: use of secure programming rules, guaranteed libraries and the simplest possible code
  • Mechanical part: More durable materials, more accurate mounting
    I don't know.
    Of course, the various exit checks apply to all cases together.

Why system support is useful for HARA

Technically, the main output of HARA is the analysis of the thought process in particular. However, HARA's analysis, like FMEA's, does not stand alone, but is made in the context of the whole project it influences and fits into:

HARA Documentation

  • It must be documented who participated in the analysis
  • Explicit requirements for HARA review (must be independent) so both investigators and reviewers of the analysis must be documented
  • There must be evidence that it actually took place – e.g. according to ISO 26262 it should be controlled by a process control system
  • Requirements must be reviewable – there must be a rational justification for them to actually help

Material coherence

  • Every HARA measure becomes a safety requirement for the product or production process
  • Safety requirements must be part of the traceability system and documented from their inception to their implementation
  • Traceability is reciprocal – it must also be possible to trace back the reasons behind the HARA analysis that led to the decision to create the requirement.

With HARA system and process support in AyMINE, you will not only have quality documentation, but also interdependence with the product documentation and the project. And also process support.

You may be interested