IF YOU DEVELOP SAFETY-CRITICAL EMBEDDED SOFTWARE, YOU ALREADY KNOW WHERE THE TIME
GOES. A REQUIREMENT IS WRITTEN. SOMEONE READS IT AND WRITES A TEST SPECIFICATION. SOMEONE ELSE READS THAT AND WRITES A TEST SCRIPT. SOMEONE ELSE RUNS IT AND ASSEMBLES THE EVIDENCE. EACH HANDOVER IS MANUAL, AND A PLACE TO LOSE TRACEABILITY.

IN THIS SESSION, DEVELOPAIR AND QA SYSTEMS WILL FOLLOW A SINGLE REQUIREMENT (FROM AN
AIRCRAFT CABIN PRESSURE CONTROL SYSTEM) ALL THE WAY THROUGH THAT CHAIN.

YOU WILL SEE REQUIREMENTS FORMALIZED AND TURNED AUTOMATICALLY INTO STATEMENT AND
MC/DC TEST CASES, A REQUIREMENTS DEFECT CAUGHT BEFORE ANY CODE IS WRITTEN <IF POSSIBLE - DEVELOPAIR TO CONFIRM>, AND THOSE SAME TEST CASES EXECUTED IN CANTATA AGAINST REAL CODE TO PRODUCE THE STRUCTURAL COVERAGE AND TRACEABILITY EVIDENCE THAT ISO 26262, DO-178C, IEC 61508 AND EN 50128 SUBMISSIONS REQUIRE.

WE WILL ALSO SHOW HOW AN AI ASSISTANT CAN HELP AN ENGINEER CLOSE ANY REMAINING COVERAGE GAPS WITHOUT COMPROMISING THE REVIEW AND GOVERNANCE A CERTIFIED PROJECT DEPENDS ON.

FOR SOFTWARE DEVELOPERS, TEST ENGINEERS, FUNCTIONAL SAFETY ENGINEERS AND ENGINEERING
MANAGERS WORKING ON EMBEDDED AND SAFETY-CRITICAL SOFTWARE.