Quality Management Systems

Eskube is a highly skilled company with multi-year experience in Quality Management systems for the Automotive Industry.

With technology increasing at an exponential growth, small-medium players are generally fully focused on products or services development and leave out the quality phase due to a lack of resources or knowledge.

We, as Eskube, quickly deploy skills and knowledge to our customers to guarantee that their products meet the highest automotive standards compliance, acting as an extension of their teams throughout all phases of the development life cycle.

ISO 26262 - Functional Safety

ISO 26262 goal is to develop Electric and/or Electronic (E/E) systems where the risk due to hazards caused by systems malfunctioning behavior are minimized and/or prevented.

Safety analysis techniques are used to examine the consequences of faults and failures of the functions, the behavior and the design of items and elements throughout the product life cycle:

11
  1. Concept
  2. System
  3. HW and SW
  4. Integration and V&V activities
  5. Post-production

ISO 26262 target is the absence of unacceptable risk due to hazards caused by malfunctional behavior of E/E systems due to:

  • Random causes (e.g., random physical defects as bridging faults and stuck-at, or by the interaction of the system with environmental factors as radiation sources alpha beta, etc)
  • Systematic causes (e.g, faults in the design of an HW element or a SW unit)
  • Systemic cause (e.g., pressure on a team to launch the product, incompetence of management or a flawed decision making process)

Functional Safety is here to ensure correct functioning of the E/E systems, including active safety related systems, against malfunctions leading to catastrophic scenarios from the safety standpoint.

11

ISO 21448 - Safety Of The Intended Functionality (SOTIF)

The goal of SOTIF, is to reach the absence of unreasonable risk due to and unintended or unexpected behavior of the system, that can result in an harmful or hazardous situation for the users.

SOTIF applies to functionalities that require proper situational awareness in order to be safe: the document is concerned with guaranteeing the safety of the intended functionality in the absence of a fault, standing right next to the Functional Safety, focused instead on mitigating risks due to system failure.

As the Functional Safety, also the SOTIF provides guidance on design, verification and validation measures. Applying these measures helps the company achieve safety in situations without failure:

  1. Design includes requirements for sensor performance
  2. Verification is implemented by building test cases with high coverage of scenarios
  3. Simulations are performed for the Validation phase

With the increase of complexity related to systems functions and features inside the automotive industry, especially for ADAS systems and Autonomous driving, there is a clear need for a systematic framework able to identify and manage the new safety challenges given by risks added to the system. It is important to address the new safety challenges that for example autonomous vehicles developers are facing, as AI and machine learning play key roles in the Automotive industry.

Some examples where SOTIF applies:

  • An ADAS feature that helps the driver keeping the lane in every moment by taking control of the steering wheel
  • An ADAS feature that brings the car to rest in-lane if it is unable to hand back a control to the driver
  • An AEB (Autonomous Emergency Braking) that detects an imminent collision and plies emergency braking accordingly
  • An ABS that prevents wheels from locking, helping the driver to optimize the braking distance.

SOTIF is here to minimize cost and effort in how a safe behavior is achieved for such complex systems.

ISO SAE 21434 – Cybersecurity

Electric and Electronic architectures and components represent a critical part for the entire automotive industry: ensuring the security of vehicles, EE architectures and components becomes a challenge not just for OEMs and Tier 1 providers, but for the whole supply chain.

The ISO 21434 specifically requires OEMs to analyze threats and risks throughout a vehicle’s life cycle in order to determine the extent to which a road user can be impacted by automotive cyber threats and vulnerabilities.

11

This process of Threat Analysis and Risk Assessment (TARA) is done by identifying vulnerabilities, attack paths feasibility and impact rating.

Automotive cybersecurity challenges are diverse. Higher the car’s electronics system is complex, and higher will be its vulnerability, which increases exponentially (e.g., SW update management system where cybersecurity measures ensure safe software updates throughout the vehicle lifecycle). Market expects the car to be safe, not only by protecting its occupants by preventing accidents, but also in terms of safety and privacy.

The standard does not address cybersecurity only for safety purposes: damage scenarios will be assessed against potential adverse consequences for stakeholders in the main independent impact categories of:

  • Safety
  • Financial
  • Operational
  • Privacy

The organization shall define a clear cybersecurity policy (and foster a cybersecurity culture) that include acknowledgement of road vehicles cybersecurity risks and executive management commitment to manage the corresponding risks by establishing and maintaining organization-specific rules and processes.

If Cybersecurity is not taken seriously in the Automotive industry, not only safety is compromised but also the impact at financial level can be critical as well.

11

ASPICE - Automotive SPICE

As all the evaluation of increasing complexity described above are taken into account, any organization operating inside the automotive industry supply chain is required to develop specific processes to be applied to all the project development phases, as well as the management, in order to guarantee the quality and safety of the final products and its integration inside the vehicle.

In this context the Automotive SPICE is a process assessment model (PAM) that defines a detailed framework that allows to determine the organization’s capability to effectively and reliably deliver software products within the automotive industry.

ASPICE as a process reference model gives a series of base and general practices that can be used to define and develop processes at any level inside the organization:

  • Management
  • System development V-cycle
  • Software development V-cycle
  • Supporting processes
  • Acquisition processes
  • Supply processes

The score resulting from the ASPICE assessment is nowadays a common indicator to evaluate the organization and products capability to meet certain standards for performance, safety and quality.

ISO 26262 - Functional Safety

ISO 26262 goal is to develop Electric and/or Electronic (E/E) systems where the risk due to hazards caused by systems malfunctioning behavior are minimized and/or prevented. Safety analysis techniques are used to examine the consequences of faults and failures of the functions, the behavior and the design of items and elements throughout the product life cycle:

  1. Concept
  2. System
  3. HW and SW
  4. Integration and V&V activities
  5. Post-production

ISO 26262 target is the absence of unacceptable risk due to hazards caused by malfunctional behavior of E/E systems due to:

  • Random causes (e.g., random physical defects as bridging faults and stuck-at, or by the interaction of the system with environmental factors as radiation sources alpha beta, etc)
  • Systematic causes (e.g, faults in the design of an HW element or a SW unit)
  • Systemic cause (e.g., pressure on a team to launch the product, incompetence of management or a flawed decision making process)

Functional Safety is here to ensure correct functioning of the E/E systems, including active safety related systems, against malfunctions leading to catastrophic scenarios from the safety standpoint.

11

ISO 21448 - Safety Of The Intended Functionality

The goal of SOTIF, is to reach the absence of unreasonable risk due to and unintended or unexpected behavior of the system, that can result in an harmful or hazardous situation for the users.

SOTIF applies to functionalities that require proper situational awareness in order to be safe: the document is concerned with guaranteeing the safety of the intended functionality in the absence of a fault, standing right next to the Functional Safety, focused instead on mitigating risks due to system failure.

As the Functional Safety, also the SOTIF provides guidance on design, verification and validation measures. Applying these measures helps the company achieve safety in situations without failure:

  1. Design includes requirements for sensor performance
  2. Verification is implemented by building test cases with high coverage of scenarios
  3. Simulations are performed for the Validation phase

With the increase of complexity related to systems functions and features inside the automotive industry, especially for ADAS systems and Autonomous driving, there is a clear need for a systematic framework able to identify and manage the new safety challenges given by risks added to the system. It is important to address the new safety challenges that for example autonomous vehicles developers are facing, as AI and machine learning play key roles in the Automotive industry.

Some examples where SOTIF applies:

  • An ADAS feature that helps the driver keeping the lane in every moment by taking control of the steering wheel
  • An ADAS feature that brings the car to rest in-lane if it is unable to hand back a control to the driver
  • An AEB (Autonomous Emergency Braking) that detects an imminent collision and plies emergency braking accordingly
  • An ABS that prevents wheels from locking, helping the driver to optimize the braking distance.

SOTIF is here to minimize cost and effort in how a safe behavior is achieved for such complex systems.

11

ISO SAE 21434 – Cybersecurity

Electric and Electronic architectures and components represent a critical part for the entire automotive industry: ensuring the security of vehicles, EE architectures and components becomes a challenge not just for OEMs and Tier 1 providers, but for the whole supply chain.

The ISO 21434 specifically requires OEMs to analyze threats and risks throughout a vehicle’s life cycle in order to determine the extent to which a road user can be impacted by automotive cyber threats and vulnerabilities. This process of Threat Analysis and Risk Assessment (TARA) is done by identifying vulnerabilities, attack paths feasibility and impact rating.

Automotive cybersecurity challenges are diverse. Higher the car’s electronics system is complex, and higher will be its vulnerability, which increases exponentially (e.g., SW update management system where cybersecurity measures ensure safe software updates throughout the vehicle lifecycle). Market expects the car to be safe, not only by protecting its occupants by preventing accidents, but also in terms of safety and privacy.

The standard does not address cybersecurity only for safety purposes: damage scenarios will be assessed against potential adverse consequences for stakeholders in the main independent impact categories of:

  • Safety
  • Financial
  • Operational
  • Privacy

The organization shall define a clear cybersecurity policy (and foster a cybersecurity culture) that include acknowledgement of road vehicles cybersecurity risks and executive management commitment to manage the corresponding risks by establishing and maintaining organization-specific rules and processes.

If Cybersecurity is not taken seriously in the Automotive industry, not only safety is compromised but also the impact at financial level can be critical as well.

11

ASPICE - Automotive SPICE

As all the evaluation of increasing complexity described above are taken into account, any organization operating inside the automotive industry supply chain is required to develop specific processes to be applied to all the project development phases, as well as the management, in order to guarantee the quality and safety of the final products and its integration inside the vehicle.

In this context the Automotive SPICE is a process assessment model (PAM) that defines a detailed framework that allows to determine the organization’s capability to effectively and reliably deliver software products within the automotive industry.

ASPICE as a process reference model gives a series of base and general practices that can be used to define and develop processes at any level inside the organization:

  • Management
  • System development V-cycle
  • Software development V-cycle
  • Supporting processes
  • Acquisition processes
  • Supply processes

The score resulting from the ASPICE assessment is nowadays a common indicator to evaluate the organization and products capability to meet certain standards for performance, safety and quality.

11
This site is registered on wpml.org as a development site.