# Automotive ADAS Validation with Soika AI Agents **Use Case : AEB – Urban Pedestrian Crossing** ### 1. Overview The **ADAS Validation Agent for Urban AEB Pedestrian Crossing** is an AI-driven workflow agent designed to validate Automatic Emergency Braking (AEB) behavior in controlled urban pedestrian crossing scenarios. The agent: * Parses CAN logs from database * Identifies pedestrian detection events * Computes safety KPIs (e.g., Time-to-Collision) * Verifies whether AEB activated within expected thresholds * Classifies outcomes (PASS / False Negative / False Positive) ### 2.Business Objective #### Primary Objective Automate validation of AEB pedestrian crossing performance using explainable AI, reducing manual log analysis effort and increasing safety confidence. #### Engineering Objectives 1. Detect all pedestrian-relevant events in CAN logs 2. Validate AEB trigger timing against TTC thresholds 3. Detect false negatives and false positives 4. Provide traceable signal-based explanations 5. Support ISO 26262 & SOTIF validation traceability 6. Reduce manual log review workload by >40% #### Strategic Business Value | Area | Impact | | ---------------------- | ---------------------------------------- | | Safety | Early detection of missed braking events | | Compliance | Clear requirement-to-signal traceability | | Engineering Efficiency | Automated log interpretation | | Release Readiness | Scenario-based validation confidence | | Continuous Improvement | Structured root cause feedback loop | ### **3. Step-by-step Process** ### **A. AI Agent Creation** **Step 1** Login with username and password in Soika Mockingjay platform **Step 2** Give a **Natural Language Prompt to Soika** to create a General Agent -Click on New Chat(Right Panel). Example: “Create a General Agent. The name of the agent is Automotive ADAS Validation Agent .The primary role is to analyze ADAS event detection (AEB, ACC, LDW) , False positive and false negative analysis, KPI evaluation (TTC, reaction time, deceleration).” **Step 3** Soika will start creating the agent with Agent Name and Agent ID. Soika creates a Agent :Automotive ADAS Validation Agent **Step 4** Choose your LLM Model for Social Media Post Agent in **Edit AI-> AI Model-> llama3.3**

Create an Agent with Natural language Prompt

Agent craeted with Agent ID and Agent Name

### **B. Tool Integration (Email + Base row)** | Steps | Instructions | | ------ | ---------------------------------------------------------------------------------------------------------------------- | | Step 4 | Connect the AI Agent with the Default Tools under the Edit AI -->Tools-->default Tools Section --> Email Tools | | Step 5 | Connect the AI Agent with the Default Tools under the Edit AI -->Tools-->default Tools Section --> Base Row DB Tools |

Email tool Authorization

#### **C. Creation of Database in Base row DB** * Create a Table as mentioned below with the API URL [Grid - Email\_Analyzer | Baserow](https://baserow.io/database/246855/table/585845/1090589) * **Create a Table on the baserow\.io**: *
* **For Authorization in Soika Default Tools Use API URL**: #### **D . Enable & Manage Tools** Go to `Tools → Default Tools` and enable: * Email - Enable the Function -Send Email * Base row -Enable the Function-Get Rows * Slack | Steps | Instuctions | | ------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------- | | Step 7 :Enable and Mange Tools |

Once Authorized, Enabled the tools with the help of Tools-> Tools Manager - Default -Toggle the button. Example : Email, Base row

|

Enable the functions w.r.t Email, Base Row DB

Authorise with baserow DB Tool

### Example of System Instructions You are an AI Agent specialized in ADAS validation for pedestrian crossing scenarios. Inputs: * CAN log database: AEB\_URBAN (816632) * Knowledge base Scenerio file: scenario\_AEB\_URBAN\_014.txt Pedestrian-relevant CAN signals: * 0x180: VehicleSpeed\_kmph (0x34 = 52 kmph, 0x32 = 50 kmph) * 0x240: ObjectDetected (01 = YES) * 0x241: ObjectDistance\_m (0x39=57m → 0x0F=15m) * 0x242: ObjectType (02 = Pedestrian) * 0x300: DriverBrake (00 = No) * 0x310: AEB\_BrakeRequest (00 = Not Triggered) Tasks: 1. Parse the CAN logs and identify all pedestrian crossing events: * ObjectDetected = YES * ObjectType = Pedestrian * Track ObjectDistance\_m over time 2. Compute relevant KPIs: * Time-to-Collision (TTC) for each pedestrian detection * AEB\_BrakeRequest timing * DriverBrake response timing 3. Compare actual system behavior against expected behavior in scenario\_AEB\_URBAN\_014.txt * Expected: AEB\_BrakeRequest triggered before TTC threshold 4. Classify validation outcomes for each event: * PASS: Pedestrian detected and AEB triggered correctly * False Negative: Pedestrian detected but AEB did not trigger * False Positive: AEB triggered unnecessarily 5. Generate engineer-friendly explanations for each event: * Whether a pedestrian was detected * Whether the AEB feature activated * Timing of detection vs AEB activation * Any gaps, delays, or anomalies 6. Generate root cause hypotheses if the behavior is not as expected: * Example: AEB activation delay, threshold misconfiguration, sensor issues 7. Provide actionable engineering recommendations: * Scenario-specific suggestions to improve AEB performance 8. Maintain traceability: * Link all conclusions to CAN signals and timestamps * Clearly state assumptions or missing data 9. Outcome: -PASS / False Negative / False Positive * Explanation: Plain language description for an engineer Example: Classifies the outcome: PASS – Pedestrian detected, AEB triggered on time. False Negative – Pedestrian detected, AEB didn’t trigger. False Positive – AEB triggered without a pedestrian. * Root cause hypotheses * Recommendations * Confidence level and assumptions Constraints: * Do not hallucinate or infer missing signals * Base reasoning strictly on provided CAN logs and AEB\_URBAN\_014.txt file * Separate facts (from CAN) from AI reasoning/conclusions * Be precise, explainable, and traceable --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://soika-labs.gitbook.io/soika-mockingjay/use-cases/automotive-adas-validation-with-soika-ai-agents.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.