Are Traditional Methods and Tools for Safety and Security Sufficient for the AIDLC of the Future?

Most of the AI-in-engineering conversation is about speed. This session is about what speed does to the paperwork, and to the arguments underneath it.

Steve Howard, Director of Product at Perforce Software, presents. The premise Perforce states is that the AI Development Lifecycle is on its way to becoming a mainstream approach for embedded software development, and that it reshapes the traditional Software Development Lifecycle which has, in Perforce’s words, long served as the foundation for safety, security, and compliance practices. That is the uncomfortable part: safety cases are built on the lifecycle, so a change to the lifecycle reaches the safety case.

What Steve Howard will explore

Per the Perforce session outline:

• How the transition from traditional SDLCs to AI Development Lifecycles (AIDLCs) will reshape embedded software development
• The impact of the AIDLC on compliance, assurance, safety, and security activities
• How standards and regulatory frameworks will evolve to support AI-driven development practices
• Where AI can help address emerging development challenges, and where its limitations remain
• Practical considerations for preparing your organization for AI-driven development and V&V workflows

Perforce frames the timing directly: now is the time to prepare for the AIDLC era while continuing to advance safety, security and compliance.

Session times

Perforce runs two broadcasts of the same session. The EMEA one lands inside the Indian working day.

Times sourced from the official Perforce registration page, which is where registration happens.

Why this matters for Indian safety-critical teams

The question in the title is not rhetorical for an Indian automotive, avionics, rail or medical device team. Assurance work here is evidence work: a MISRA compliance record, a tool qualification argument, a traceable path from requirement to test. Every one of those artefacts assumes a human wrote the code and a defined process produced the evidence. An AIDLC changes who writes the code and how fast the evidence has to be regenerated, and the standards that govern the evidence are still catching up.

That is the gap this session addresses, and it is the reason the standards-evolution bullet is the most useful one on the agenda. Teams committing to a five-year programme today are choosing tooling against regulatory frameworks that will not look the same when the programme ships.

Perforce QAC, formerly Helix QAC, and Klocwork sit on the verification side of exactly this problem: they are the quality gates that decide whether code, whoever or whatever produced it, is admissible. For a written treatment of the adjacent question, how AI participates in fixing what static analysis finds while keeping a human in the approval loop, see AI-Assisted Code Remediation for Safety-Critical C and C++.

Speaker

Why GSAS is sharing this

GSAS Micro Systems is the authorized India engineering partner for Perforce static analysis, with application engineering, MISRA compliance support and CI/CD integration from Bengaluru, Hyderabad, Chennai, Pune, Mumbai and Delhi NCR. Perforce is the organizer of this webinar; GSAS is highlighting it.

If you want to work through what an AI development lifecycle does to your own ISO 26262 or DO-178C evidence chain, talk to us before or after the session.

Reserve your seat on perforce.com →