Integrating Advanced Technologies with

Safety into Automated Driving Features

A Structured Approach to Enable Integration of Standalone Components into Automated Driving Features

Introduction

In the rapidly evolving landscape of automated driving, integrating non-automotive technologies into safety-critical systems has become increasingly common. Whether it’s hyper-precise GPS, cutting-edge sensors, or advanced software components, these technologies must meet stringent automotive standards to ensure safety and reliability. For many non-automotive suppliers, the journey to achieving compliance with standards like ISO 26262 can seem overwhelming.

This challenge is not theoretical to me—it's one I’ve tackled firsthand. As the lead engineer for a project integrating hyper-precise GPS technology into automated driving features, I guided a telecommunications company, with no prior automotive experience, through the process of aligning with ASIL (Automotive Safety Integrity Level) requirements. The lessons I learned from that experience have shaped my approach to similar projects and inspired this portfolio entry. Here, I’ll share the general methodology I used, which can be applied to other scenarios like integrating sensors, software components, or hardware modules into automated driving systems.

Step 1: Understand the Technology and Its Gaps

One of the first hurdles is understanding the product’s unique technical capabilities and identifying the gaps between its existing design and the functional safety requirements of the automotive industry.

In my project, the GPS technology was initially developed for telecommunications applications. While it excelled in accuracy and reliability, there was no concept of functional safety compliance or automotive-specific considerations. My role involved dissecting the architecture and functionality of the GPS system to define how it could be integrated in an automated driving environment with ASIL compliance.

General Application:
For other components, such as sensors or software modules, this process involves analyzing the technology’s integration points and identifying where functional safety considerations (e.g., fault detection, redundancy) need to be addressed.

Step 2: Educate and Align Stakeholders

Non-automotive suppliers often lack exposure to functional safety standards, which can lead to confusion or misaligned priorities. My approach was to educate and align the supplier’s teams—ranging from software developers to senior managers—on the fundamentals of ISO 26262.

I led workshops to introduce key concepts like hazard analysis and risk assessment (HARA), safety goals, and the idea of developing the GPS as a Safety Element Out of Context (SEooC). These sessions were tailored to different audiences:

  • Engineers received deep dives into technical aspects like requirement development and validation strategies.

  • Managers were guided on timelines, deliverables, and the organizational structure required for compliance.

General Application:
Whether you’re working with lidar sensors or real-time operating systems, a shared understanding among stakeholders is critical. Tailor your training to the audience’s level of expertise and use relatable examples from their domain to make complex concepts approachable.

Step 3: Define a Clear Compliance Strategy

Given the GPS supplier’s lack of functional safety experience, we focused on developing the component as a Safety Element Out of Context (SEooC). This allowed us to define the scope of compliance activities without embedding the component into a specific system during development.

My team and I outlined a strategy that included:

  • Defining safety goals and Functional Safety Requirements (FSRs) to address potential hazards.

  • Developing a high-level architecture that identified critical elements requiring safety measures.

  • Establishing a timeline and roadmap for producing ISO 26262 work products, such as safety analyses and test plans.

General Application:
For other technologies, defining the compliance strategy early—whether as a SEooC or as part of a complete system—can save significant time and resources. Focus on identifying safety-critical interfaces and potential failure modes as foundational elements of the plan.

Step 4: Lead Collaborative Efforts

As the lead engineer, I spearheaded cross-disciplinary collaboration to ensure progress. This involved delegating tasks to team members, facilitating alignment between software and hardware teams, and working closely with management to secure resources and buy-in.

I also held recurring one-on-one sessions with key stakeholders to address roadblocks and clarify requirements. These efforts ensured that all contributors, regardless of their functional safety experience, were aligned and productive.

General Application:
For any component being integrated, strong leadership and collaboration are essential. Foster open communication across teams, and create a structured plan for delegating tasks and resolving conflicts.

Step 5: Deliver an Actionable Roadmap

At the conclusion of the GPS project, I delivered a comprehensive roadmap outlining:

  • All activities required for ASIL compliance, categorized by ISO 26262 sections.

  • Roles and responsibilities for engineers, testers, and managers.

  • A high-level timeline with specific milestones for producing work products and demonstrating compliance.

This roadmap served as a practical guide for the supplier, giving them confidence in their ability to adapt their technology to the stringent requirements of automated driving systems.

General Application:
For other integrations, such as radar sensors or AI-based software modules, providing a clear and actionable plan enables suppliers to focus on the most critical activities and achieve compliance efficiently.

Broader Implications for Automated Driving Systems

My experience with integrating hyper-precise GPS technology highlighted a universal truth: the process of adapting non-automotive components to meet automotive safety standards is as much about leadership and education as it is about technical expertise.

This approach—understanding the technology, educating stakeholders, defining a clear strategy, leading collaborative efforts, and delivering actionable plans—can be applied to any scenario where non-automotive technologies are being integrated into automated driving systems.

The key takeaway is that functional safety is not just a checklist; it’s a mindset. It requires bridging the gap between technical capabilities and safety-critical requirements, fostering collaboration across disciplines, and empowering teams to navigate the complexities of standards like ISO 26262.

Conclusion

Integrating non-automotive technologies into automated driving systems is a challenge, but it’s one that can be successfully navigated with the right approach. My experience with hyper-precise GPS technology has shown me the importance of strategic planning, stakeholder alignment, and strong leadership in achieving functional safety compliance.

If you’re leading a similar effort—whether for a sensor, software module, or hardware component—remember: the process may be complex, but with a structured methodology and a focus on collaboration, you can turn a daunting task into a transformative success.