FuSa and SOTIF: Porsche Engineering’s integrated ADAS safety process

Porsche Engineering explains how functional safety (FuSa) and SOTIF work together for ADAS and Level 3 automation, using ODD and iterative validation. Read on.

Modern driver assistance systems and future automated driving functions are becoming so complex that safety can no longer be reduced to a simple promise that “nothing will break.” In a recent piece for Porsche Engineering Magazine (issue 1/2025), Porsche Engineering argues that real-world safety now depends on two complementary layers: functional safety (FuSa) and safety of the intended functionality (SOTIF).

FuSa addresses the classic engineering question: what happens if a hardware or software component fails—whether it is a sensor fault or a software error? The approach relies on structured analyses of potential faults in both software and electronics, evaluating their effects and applying technical and procedural measures to mitigate safety-critical outcomes. SOTIF, however, points to a different trap in modern systems: situations where everything is functioning as designed, yet the function still fails to handle reality—such as a camera being blinded by the sun or an algorithm missing a cyclist in a complex scene. In that world, it is not enough to manage failures; developers must understand the limits of the function itself and show that it behaves safely at those limits.

The article frames FuSa and SOTIF as two sides that only deliver value when combined. FuSa makes hardware and software reliable, while SOTIF asks whether the capabilities of those reliable components are specified and proven well enough for safe operation in the real world. The processes differ as well: functional safety follows a structured lifecycle with systematic fault analyses and safety mechanisms, while SOTIF is described as an exploratory, iterative discovery process. Developers specify, test, revise, and repeat until the remaining risk is acceptable—especially in the corner cases and edge cases where automated functions tend to be challenged.

A major focus is the jump from advanced Level 2 systems to Level 3. As long as the driver retains full responsibility for vehicle manoeuvres (Levels 1–2), degradation and warning concepts can still lean heavily on human supervision. From Level 3 onward, that changes: the driver no longer has a constant duty of attention, so the system must be able to handle failures autonomously, at least for a certain period. That is why the step from Level 2 to Level 3 is described as particularly demanding—and expensive—because redundancies in vehicle electronics increase rapidly along with the associated development workload.

To keep “almost infinite” real-world complexity within engineering reach, the development is anchored in an Operational Design Domain (ODD)—a defined set of operating conditions the system is designed to handle. Within that domain, scenarios are organized into a portfolio and broken down into discrete cases the function must master safely. Just as important, the system must detect early when it is approaching the boundary of that ODD, so that control can be handed back to the driver or the vehicle can be brought to a safe stop within the domain’s limits.

The difference between FuSa and SOTIF becomes clear in practical examples. In an SAE Level 3 highway scenario, a radar hardware defect could stop distance data from being provided. FuSa is needed to identify such failures through safety analyses and to verify them with safety mechanisms—where redundancy can help prevent a local fault from turning into a global loss of sensor availability until responsibility is transferred back to the driver. SOTIF comes into play when there is no fault at all, yet performance limits still create risk. If a system fails to detect a narrow silhouette and approach trajectory—such as a motorcycle under unfavorable light or weather—an automated lane change might create a collision risk even though hardware and software are behaving correctly. In that case, SOTIF calls for analysis and validation across operating scenarios, with weaknesses corrected in the next design iteration through updated specifications and implementations.

Demonstrating safety increasingly depends on large amounts of test data, much of it generated through simulation. One of the hardest problems remains “unknown unsafe scenarios”—dangerous situations not considered during development due to insufficient specifications or shifting operating conditions. Discovering and reducing such scenarios is described as the core objective of SOTIF, and it becomes central as systems take on more responsibility for driving.

The article also notes that safety demands will grow further as AI-based methods become more common in safety-critical systems. It points to an international draft, ISO/PAS 8800, focusing on the safety of AI when it is part of the end product, and to ISO/TS 5083, which targets the safety of automated driving functions and considers not only onboard vehicle components but also off-board elements and their impact on overall safety. Together with the rise of safety-oriented V2X communication, this suggests a broader trend: even technologies intended to enhance safety introduce new dependencies and potential fault sources—and these must be safeguarded with the same consistency.

The conclusion is pragmatic. Safety requirements are tightening not because vehicles have become less reliable, but because automated functions have assumed more responsibility. It is no longer enough to ensure components work correctly; developers must also prove that the system can handle the boundaries of its own capabilities safely—even though it is impossible to test every conceivable scenario in advance.