By Richard Obrien
The key to faster, safer product development is to start smart - not catch up hard. In this blog, we’ll explore how the "Shift Left" approach transforms functional safety from a last-minute checklist into a proactive strategy that saves time, cost, and headaches.
“Shift left” is synonymous with everything related to product development. However, it is not a new concept; it first emerged in the 1990s but gained significant traction in the mid-2010s, mainly in software development. “Shift left” refers to a methodology that emphasizes addressing tasks such as design, verification, quality assurance, safety, and security considerations to earlier stages of the product development lifecycle. This approach aims to proactively address or prevent issues, mitigate risks, and solve problems as early as possible.
Transforming to a Unified Approach
Safety integration under ISO 26262, ISO 21448, ISO 8800, IEC 61508, and similar standards benefit from early engagement, ensuring malfunction analysis, safety mechanisms, and compliance checkpoints align with evolving design phases. Analog Devices, Inc. (ADI) Functional Safety Office (FSO) adopts reusable templates and iterative processes to streamline safety tasks and foster collaboration across hardware, software, and systems teams starting at time 0. Ultimately, from a functional safety (FuSa) perspective, “shift left” transforms safety from a compliance obligation into a strategic enabler for innovation and customer trust.
PSD0 & VIR – Before, Not After
Early engagement is key. Gone are the days when ADI was primarily a hardware component developer, and rolling up to a PSD (Project Status Decision) meeting with a few marketing and design architecture slides was sufficient; it has grown significantly into a system developer where hardware, software, safety, and security are integrated to meet evolving customer needs. Therefore, as indicated in the high-level product development model below, in (Fig. 1), engagement between all disciplines early in the development lifecycle is fundamental to building the product our customers want - when they want it.
Figure 1: Product Development Model indicating early engagement in FuSa activities
Workflow – Functional Safety Context
The Functional Safety Context specifies and verifies the context for product development within the ADI26262 functional safety development process. From a safety perspective, the FSO aims to enable development teams with tools and templates to help guide them to quickly build safety concepts and define top-level safety requirements. For example, using a custom Functional Safety Context template, teams are guided on how to structure the data and analysis:
- Inputs
Quality Managed (QM) - Business or Mission Analysis
QM- Stakeholder Needs, Use case(s) definition, Assumptions of Use (AoU)
FuSa - Input Safety Requirements, i.e., from customers, marketing, regulatory bodies
FuSa - Safety AoUs (if known)
- Analysis
Build a Preliminary System Architecture - Systems Modeling Language (sysML)
Define System Functions & Malfunctions
System Analysis, classification of the effect of the malfunction
- Outputs
Product level - Top-level Safety Requirements (TLSR), Functional Safety Requirements (FSR), Safe States, AoUs
- Verification
Verification of the Completion of Functional Safety Context
- Report
Automated report of the Functional Safety Context (for archive in Document Management System (DMS)
By following this guidance, the required safety activities are complete; therefore, the Functional Safety Context Report provides the evidence to support the PSD0 phase of the product development.
Workflow – Technical Safety Concept
Assuming PSD0 is successfully passed, preparation for Value and Impact Review (VIR) can proceed. From a safety perspective, this involved developing a Technical Safety Concept (TSC). In summary, the objective of the TSC is to:
- Derive the product level Technical Safety Requirements (TSRs), from the Functional Safety Context TLSRs, and allocate them to the preliminary design elements
- Identify safety measures and demonstrate how they contribute to a safe design and the achievement of the allocated safety requirements
- Develop a system architectural design that will meet the allocated safety requirements
Again, the FSO provides a custom TSC template to guide teams on how to structure the data and analysis:
- Inputs
FuSa - Functional Safety Context
- Analysis
Build the Architecture Block Diagram (sysML)
- Outputs
Product level - Technical Safety Requirements, Safety Measures, Safety AoUs
- Verification
Verification of the Completion of Technical Safety Concept
- Report
Automated Report of the Technical Safety Concept (for archive in DMS)
Therefore, the required safety activities for VIR are complete, and if successfully passed, preparation for PSD1 can proceed. From a safety perspective, this involved the creation of a Safety Plan, executing preliminary Safety Analysis activities and required Confirmation Reviews…but this is all a topic for another day.
“Shift left” - Building Better, Faster, and Safer
For decades, “Shift left” has proven to be a methodology built on solid thinking and systematic development steps that align well with sound engineering principles. ADI’s “move up the stack” from low-level component developments to higher-level system and application solutions seamlessly ties in with “Shift left”. In fact, one might argue that they are not mutually exclusive…so ADI is indeed “Ahead of What’s Possible”, and our safety culture epitomizes that.
Read more from the Automotive FuSa blog series.