Skip to the main content.

8 min read

Integrated Solutions to Align Product Development and Safety Implementation

Integrated Solutions to Align Product Development and Safety Implementation
Integrated Solutions to Align Product Development and Safety Implementation

Integrated Solutions to Align Product Development and Safety Implementation

The functional safety standard, ISO 26262:2018, can be as demanding as it is rewarding. Implementing functional safety requires an organization to commit time, resources, and brainpower to the task. Certifying compliance to the standard requires a thoughtful approach, even for newer companies. More established organizations, which have been doing business for longer, must also find intelligent ways to integrate new product development solutions in order to align with the implementation of functional safety practices.

We’re going to look at some of the ways creating functionally safe automotive software products can present unique challenges to more-established companies, along with the rewards of doing so. Along the way, we’ll examine some of the tools and services LHP offers to help your organization transition to functional safety, whether it is an established company, or brand-new.

New call-to-action

Established organizations face unique challenges

When comparing the implementation of functional safety in an established organization versus a newer organization, it can be said that newer companies may find it easier to ensure functional safety is “baked into” their culture from the outset. Functional safety exists as a foundational concept for them because they know that the requirements of that standard are on the horizon before they even draft their business plan.

Typically, a younger company has fewer entrenched practices to overcome and rewrite than an established organization, whose history may span decades or even generations, and may have many years’ worth of ingrained practices and norms to match. Thus, companies that have been in business for longer periods face unique challenges when approaching functional safety. However, many companies, even newer ones, must either implement functional safety for the first time or possibly review or update their existing practices to ensure new products are being developed and produced in accordance with the standard.

An organization’s engineering culture could already be quite robust, so it might require only minor changes and documentation to become ISO 26262 compliant. A company may already be operating at high levels of engineering excellence before pursuing functional safety certification. But, as manufacturers continue to require suppliers to comply with functional safety standards in more situations, it becomes increasingly desirable to understand and implement ISO 26262 in order to ensure that the products produced by the organization are truly functionally safe.

Because a full shutdown and large-scale re-tool is typically an undesirable option, an organization could conceivably transition to ISO 26262-compliant development and production via one business unit or product type at a time. This might entail changing over product development, safety practices, or cybersecurity protocols in planned increments while maintaining an acceptable level of overall production. LHP offers training, testing, and consulting in functional safety and its component or adjacent disciplines and can guide companies in making this transition.

In the short term, this effort might be misinterpreted as just another added expense of doing business in the automotive industry. In reality, integrating functional safety practices, and gaining ISO 26262 compliance for one’s existing operation, brings with it many rewards. Many suppliers may not be in a position to quote new business, or even maintain relationships with existing customers if they have not achieved functional safety compliance.

Benefits of aligning functional safety with product development

What does functional safety do?

The benefits of achieving certification proving compliance with ISO 26262 far outweigh the effort of implementing a functional safety practice. ISO 26262 provides the functional safety standards dictating the development and testing of the millions – or hundreds of millions – of lines of code present in modern vehicles. Functional safety’s ultimate priority is to ensure the end user, their property, and anyone around them, is exposed to minimal risk. For automotive manufacturers and their suppliers, this focuses on electrical and electronic (E/E) systems and the software that those systems operate on.

Here’s a look at what’s driving the proliferation of code in software, and the benefits that functional safety introduces in light of this ongoing and accelerating trend.

The proliferation of code

It’s becoming more accepted that all modern vehicles are Software-Defined Vehicles (SDVs), simply owing to the sheer amount of software required to operate them. Whether internal combustion (IC) or electric (EV), car, truck, motorcycle, or bus, nearly every vehicle produced today is going to be a vehicle defined by the software that governs its functions, its features, and its safeguards against misuse. This is even more true for those vehicles whose features include autonomous or semiautonomous functions (advanced driver assistance, or ADAS, is a series of features found on an ascending scale of vehicle autonomy – all of which are heavily software dependent).

Software-Defined Vehicles (and the near totality of the automotive industry) comprise a wide variety of vehicles, uses, and purposes. That variety, therefore, demands a wide range of software solutions. One advantage of functional safety is that acts as a bit of a funnel, regularizing that variety somewhat. The AUtomotive Open System ARchitecture platform (AUTOSAR) is one facet of a robust functional safety culture that helps produce and define this regularizing aspect. AUTOSAR provides an open software architecture that is standardized across the automotive industry. This fosters collaboration and speeds up the development and testing of software applications.

Compliance to the correct degree

Aside from potentially increasing the speed of development, integrating functional safety into product development also leads to increases in the end product’s quality and reliability. Integrating functional safety into development can also lead to increased trust from both customers and consumers, whether in an application, a system, or a feature. This is good for the automotive market, and especially good for those organizations within the market that are in a posture to maximize and capitalize on that trust, those organizations with full functional safety certification.

A company that can demonstrate and document its commitment to the best current practices must realize that this excellence carries over into the financial side of things. An organization showing its capacity for producing applications that place safety first, and that are effective and efficient, and that can be rapidly developed and brought to market, is an organization that will enjoy advantages in that market.

Now that we’ve had an overview of functional safety’s advantages like increased efficiency in product and system development, reliability, safety (including, notably, cybersecurity), and market advantage, we can turn to some of the things you might expect as your company integrates LHP’s custom functional safety solutions. A few major touchpoints of successful functional safety implementation are a paradigm shift, a safety culture, executive awareness, engineering QA, and the concept of “compliance to the correct degree.” Let’s examine these touchpoints and their relation to a successful functional safety implementation.

New call-to-action

Risk assessment

What is the probability that a component would fail in a given situation?

Hazard analysis and risk assessment (HARA) is the first step in implementing any functional safety plan. This is only appropriate, as ISO 26262 is a risk-based standard. In the functional-safety-conscious organization’s pipeline, this step takes place early in product development. The standard’s authors place it in the “concept” phase. This step is important because once risk is considered “known,” the safety goals of the project can be outlined.

The level of risk present in the project defines the steps, tools, and techniques required to manage it. Risk assessment results, once analyzed, can be expressed as an Automotive Safety Integrity Level (ASIL). ISO 26262 created ASIL as a risk assessment scheme and a way to set the “integrity requirements,” or safety goals.

ASIL rating is a measure of inherent risk, calculating these factors:

  • The severity of possible incidents in the event of a failure.
  • The possibility of exposure to a hazard.
  • The controllability of the component or feature by the driver in case of an emergency.

The risk factors, once tallied and calculated, produce a value. From that value, the ASIL is extrapolated:

  • ASIL A is the lowest level of hazard that must be addressed. When determining ASIL versus the assessment factors, ASIL A is generally found in low to mid severity, mid to high exposure, and typically median controllability risk. This ASIL is usually assigned to heating and cooling components and body control units.
  • ASIL B carries a higher risk value. This ASIL typically falls in the median severity, mid to high exposure, and again median controllability ranges. For instance, in single-point hardware failures, ASIL A is not considered, but ASIL B is allowed to fail at the rate class of 1 or 2. Class 2 can be up to ten times the rate of class 1, but either failure rate class is allowed at ASIL B. The exact rates are calculated for each unique situation, and the requirements grow more exact as the ASIL scale ascends. Typical components found at this ASIL include the vehicle’s instrument cluster or brake lights.
  • ASIL C, in the above example, is held to the failure rate of Class 1, and only allowed to fail at Class 2 if dedicated measures are also taken. ASIL C often comprises battery management components and adaptive cruise control, and is often assigned to components whose determining factors fall into mid to high severity, mid to high exposure, and mostly high controllability risk classes.
  • ASIL D has the highest degree of risk; its mitigating requirements are therefore the most extensive. In the instance of the hardware failures discussed above, components whose safety goals are interpreted at ASIL D must have not only a Class 1 fail rate but also additional dedicated measures. The failure rate of Class 1 is 1/10th the rate of Class 2. ASIL D is often found assigned to components such as antilock braking or airbag controls. This ASIL is assigned to components with only high severity, only high exposure, and only high risk in controllability.

(ASIL determination matrix source: ISO 26262-3, hardware fail rating targets source: ISO 26262-5, Table 7. Failure rating class requirements source ISO 26262-5, paragraphs

There are multiple sub-classes of each of the three risk factors which make assigning an ASIL rating highly dependent on individual combinations of components and events. There is a fifth rating, ASIL QM. This is a non-hazard rating and no safety assurance controls are needed for this ASIL rating.

Due to the careful layering of intentional redundancy within the standard, even as some requirements drop off or become less strongly recommended at lower ASIL levels, it’s also true that a process or application which can comply with ASIL D also exceeds the requirements for all lower ASILs.

Risk management

How do we control the timeline and manner of a component’s failure?

Risk management and mitigation are the entire reason for ISO 26262 to exist. The greater the risk, the more stringent the standard becomes in terms of the testing techniques used on individual applications or systems. Put another way, as the risk factor associated with a particular project increases, the design and testing requirements, for example, will change to address that increase.

The HARA is also used to begin identifying the safety goals for a project. Safety goals are:

  • Plans to mitigate safety risks that could be triggered by the failure of an individual component or system of components.
  • Objectives for the design’s feature in response to the identified hazards.
  • Must address specific events or combinations of events, for example, unintended acceleration or braking, or specific steering issues.

Once the safety goals are established, functional safety-oriented design can begin.

LHP can help your organization understand how to generate and interpret HARAs and the ASIL of electrical and electronic (E/E) components your company produces, with our custom training and consulting packages. They’ll help get your organization ISO 26262-compliant that much faster, giving you clear avenues to mitigating risk, limiting liability, and finding an advantage in the marketplace.

New call-to-action

Product and application lifecycle management tools

Another entry in the suite of solutions LHP offers is training and consultation in Product Lifecycle Management (PLM), most specifically Application Lifecycle Management (ALM). ALM tools help track and document the processes – and methods – by which your organization’s software (for E/E components) is developed and controlled.

Instituting and defining your organization’s ALM as a robust system makes certain that you are using the correct lifecycle management tools for your company’s products, and that you’re getting the most out of those tools to ensure high efficiency from your software team. This also helps to make sure your customers and the end user will receive the best possible software from your company, for their intended use.

LHP offers custom Application Lifecycle Management consulting packages to help your organization integrate process workflow assessments and safety analyses, avoid the pitfalls of ALM implementation, and get on your way to functional safety compliance.

Intelligent implementation makes the difference

While some companies consider implementing a functional safety plan to be an unnecessary burden, an unwanted expense, or an unwelcome drain on their resources, this thinking often ignores or diminishes the benefits waiting on the other side of that effort. With LHP on your side acting as consultants and trainers or providing expert personnel to guide your organization through, deciding to implement functional safety can be a far better experience. Your company can implement ISO 26262 successfully, bringing you advantages in the marketplace and the knowledge that your products have been made as safe as possible.

AUTomotive Open System ARchitecture (AUTOSAR) Standardized Interfaces

AUTomotive Open System ARchitecture (AUTOSAR) Standardized Interfaces

AUTomotive Open System ARchitecture (AUTOSAR) Standardized Interfaces Standardized AUTOSAR interfaces are one of three types of interfaces between...

Read More
AUTOSAR From the Automotive Industry’s Perspective

AUTOSAR From the Automotive Industry’s Perspective

AUTOSAR from the automotive industry’s perspective Feature innovation in automotive product development started drifting away from hardware and...

Read More
SME Interview: ALM Tools for ISO 26262 Compliance

SME Interview: ALM Tools for ISO 26262 Compliance

-An Interview with Adam Saenz and Nathan Haynes From LHP Engineering Solutions

Read More