Skip to main content

Supercharge Your MBSE Workflow: AI for Automotive Requirements Analysis

· 7 min read
Blagoje Mrkic
Model based Systems Architect

Welcome back to MBSE Explained! In my years as a systems architect in the automotive world, I’ve seen the volume and complexity of requirements explode, especially with the rise of EVs. We juggle thousands of customer needs, regulatory standards, and technical constraints. Manually sifting through these, ensuring clarity, consistency, and traceability, is a monumental task that’s ripe for error. But what if we could bring in an intelligent assistant to help us manage this complexity?

That's where Artificial Intelligence, specifically Large Language Models (LLMs), comes into the picture. This isn't about replacing the systems engineer; it's about empowering them. Today, we're going to explore a practical, secure, and powerful way to integrate AI into the very foundation of our work: evaluating customer requirements (Sys1) and deriving system requirements (Sys2). We'll focus on using local, private tools like Ollama and the automation platform n8n to build a workflow that enhances our MBSE process without compromising intellectual property.

Why This Matters: The Automotive Requirements Challenge

Before we dive into the "how," let's establish the "why." In the automotive industry, requirements are everything. A single ambiguous customer requirement can lead to costly rework, failed validation tests, or even safety issues that trigger recalls.

Here’s what we’re up against:

  • Volume: A modern EV can have tens of thousands of requirements spanning everything from powertrain performance to infotainment user experience.
  • Ambiguity: Customer requirements are often written in natural language, full of vague terms like "fast," "intuitive," or "reliable."
  • Consistency: Ensuring that a requirement for the Battery Management System (BMS) doesn't contradict a requirement for the powertrain controller is a complex, manual checking process.
  • Traceability: Linking high-level customer wants (Sys1) to concrete, testable engineering specifications (Sys2) is a core principle of MBSE and standards like ISO 26262, but it's labor-intensive.

Automating the initial analysis of these requirements allows us to catch issues earlier, enforce quality standards, and free up engineers to focus on what they do best: designing innovative systems.

The Tech Stack: Local and Secure AI

To build this workflow, we need a few key components. The emphasis here is on local control—critical for protecting sensitive automotive IP.

  • Your MBSE Tool (The Hub): This is your source of truth, whether it's Cameo Systems Modeler, Capella, or another platform. It holds your system model and requirements.
  • Ollama (The Brain): Ollama allows you to run powerful open-source LLMs (like Llama 3 or Mistral) directly on your own machine. This is a game-changer because your data never leaves your network. No sending proprietary requirements to a third-party cloud API.
  • n8n (The Glue): n8n is a workflow automation tool that connects different applications. Think of it as the nervous system that receives a signal from your MBSE tool, sends data to Ollama for processing, and routes the results back. It has a self-hosted option, keeping your entire workflow private.

Workflow 1: AI-Assisted Sys1 Customer Requirement Evaluation

Our first goal is to improve the quality of incoming customer requirements before they are formally accepted into the system model.

The Goal: Automatically analyze a new customer requirement for clarity, completeness, and ambiguity.

The Automated Steps:

  1. Trigger: The process starts when a new customer requirement is created in your requirements management tool (like Jira or Jama) or entered into your MBSE tool. This can trigger a webhook that starts our n8n workflow.

  2. n8n Receives Data: n8n catches the requirement text, its ID, and any other relevant metadata.

  3. Prompting Ollama: n8n sends the requirement text to your local Ollama instance with a carefully crafted prompt. This is where the magic happens. The prompt might ask the LLM to:

    • "Analyze the following requirement for ambiguity, vagueness, and non-testable statements."
    • "Rate the quality of this requirement on a scale of 1-5 based on the SMART (Specific, Measurable, Achievable, Relevant, Time-bound) criteria."
    • "Identify key parameters and their values. If a parameter is missing a value, flag it."
    • "Suggest a category for this requirement (e.g., Performance, Safety, HMI, Charging)."
  4. Return and Update: The LLM sends its analysis back to n8n in a structured format (like JSON). n8n then uses the API of your MBSE or requirements tool to post the AI's feedback as a comment or update custom fields.

Automotive Example:

  • Input Requirement: "The EV should have a fast-charging capability."
  • AI Analysis Output:
    • Ambiguity Flag: The term "fast-charging" is ambiguous.
    • Missing Parameters: Lacks specific charging power (e.g., 150 kW, 350 kW), charging standard (e.g., CCS, NACS), and target timeframe (e.g., 10-80% state of charge in under 30 minutes).
    • Suggested Category: Powertrain::Charging
    • Quality Score: 2/5 (Not specific or measurable).

A systems engineer now sees this feedback instantly, allowing them to go back to the stakeholder for clarification before accepting a poor-quality requirement into the baseline.

Workflow 2: AI-Powered Sys2 System Requirement Derivation

Once we have a clean Sys1 requirement, we need to derive the technical system requirements that engineers will actually build and test against.

The Goal: Assist the engineer in creating draft Sys2 requirements that are traced from a Sys1 requirement and consistent with the existing system architecture.

The Automated Steps:

  1. Trigger: An engineer marks a Sys1 requirement as "Validated." This triggers a new n8n workflow.

  2. Context Gathering: This is more advanced. The n8n workflow could query the MBSE tool to gather context. For example: "For this Sys1 requirement related to range, fetch the existing system architecture for the battery pack and powertrain."

  3. Advanced Ollama Prompt: n8n sends the validated Sys1 requirement plus the architectural context to Ollama. The prompt could be:

    • "Given the customer requirement: 'The vehicle must achieve a 500 km range (WLTP)', and the system architecture context: '800V battery system, dual-motor AWD', propose 3-5 draft system requirements for the following components: Battery Pack, Powertrain Control Module, and Body Control Module."
  4. Draft Generation: The LLM generates potential Sys2 requirements. It's not just making things up; it's using the context you provided to make educated suggestions.

Automotive Example:

  • Input Sys1 Requirement: "The vehicle must achieve a 500 km range (WLTP)."
  • AI-Generated Draft Sys2 Requirements:
    • For Battery Pack: The battery pack shall have a minimum usable energy capacity of 85 kWh.
    • For Powertrain Control Module: The powertrain control module shall implement an eco-driving mode that limits peak power draw to optimize for energy consumption below 170 Wh/km.
    • For Body Control Module: The HVAC system shall utilize a heat pump for cabin climate control to minimize range reduction in cold weather.

Let's be clear: These are drafts. The AI is acting as a knowledgeable partner, suggesting a starting point. The systems engineer remains the ultimate authority, responsible for reviewing, refining, and formally approving these requirements in the model. This process accelerates the work, prevents "blank page" syndrome, and ensures all relevant system components are considered.

Conclusion: Your New Intelligent Assistant

Integrating local LLMs and automation into your MBSE workflow isn't about letting a machine take over. It's about building an intelligent assistant that handles the tedious, repetitive, and error-prone aspects of requirements analysis. By using a secure, self-hosted stack like Ollama and n8n, we can leverage the power of AI to improve requirement quality, accelerate development cycles, and reduce risk—all without ever sending our company's secrets to the cloud. This frees up engineers to focus on the complex, creative problem-solving that leads to breakthrough automotive systems.

What are your thoughts on using AI in requirements engineering? Have you experimented with LLMs or automation tools in your MBSE workflow? Share your experiences and questions in the comments below! Together, we're simplifying systems for smarter EVs.