Downfall of the German Automotive industry in one Lost Decade.

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.

AI powered requirements with MBSE

Welcome back to MBSE Explained! Today, we're diving into one of the most transformative shifts in the automotive industry: the rise of the Software-Defined Vehicle (SDV). Modern cars are no longer just mechanical marvels; they are complex supercomputers on wheels, running on upwards of 300 million lines of code. This explosion in software complexity presents an enormous challenge for traditional development methods. How can automakers manage this digital beast while continuously delivering new features, enhancements, and security patches to customers?

The answer lies in a paradigm shift powered by Model-Based Systems Engineering (MBSE). By creating a modular, resilient, and evolvable software architecture from the ground up, MBSE provides the blueprint for the car of the future—one that improves over time through seamless Over-the-Air (OTA) updates. In this post, we'll explore why MBSE is the critical enabler for the software-defined automotive ecosystem.

V-model inside Model Based Systems Engineering. How to navigate in this model.

SysML v2: The Next Frontier in Automotive System Modeling and why.

Welcome to MBSE Explained, where we demystify Model-Based Systems Engineering for the cutting-edge automotive and Electric Vehicle (EV) industry. I've seen firsthand that the power of MBSE isn't just in the tools, but profoundly in the methodology guiding their use. A robust methodology acts as the blueprint for success, ensuring your MBSE initiatives truly drive innovation and efficiency in complex EV development. Without it, even the most sophisticated models can become an unmanageable mess.

The Anatomy of a Great MBSE Methodology​

What separates a truly effective MBSE methodology from one that falters? A great methodology provides clear, consistent guidelines, ensuring everyone on your team, from powertrain engineers to software developers, speaks the same modeling language (e.g., SysML). It must be scalable, adaptable to projects ranging from a single converter system to an entire EV architecture, and align with industry standards like ISO 26262 for safety-critical components. Crucially, it fosters collaboration, reusability, and traceability across the entire system lifecycle.

Conversely, a methodology can break down if it's too rigid, lacking stakeholder buy-in, or poorly integrated with existing tools and processes. A "one-size-fits-all" approach often fails in the diverse landscape of automotive projects, leading to frustration and inefficiency. Lack of training or clear objectives also quickly derails even the most well-intentioned methodologies.

Pioneering Methodologies for Automotive & EV​

Let's look at two distinct approaches proving valuable in the automotive and EV space:

1. No Magic Grid (Structured Modeling)​

Often conceptualized from the principles within resources like the "No Magic Grid Book of Knowledge," this approach emphasizes highly structured and consistent modeling practices. It leverages tools like Cameo Systems Modeler to ensure rigorous application of SysML, creating a "grid" of interconnected model elements that ensures traceability from high-level requirements to detailed design specifications. For automotive systems, especially those with stringent functional safety needs (e.g., ADAS, battery management systems), this methodology ensures completeness, consistency, and a strong foundation for verification and validation. It's about building a robust, interconnected model that leaves no room for ambiguity.

2. AIM - AI-assisted MBSE with an Object-Oriented Approach​

AIM represents the future, combining the power of Artificial Intelligence with object-oriented MBSE principles. An object-oriented approach focuses on designing reusable, modular system components (e.g., an "EV Charging Module" or "BMS Control Unit") with well-defined interfaces and behaviors. When augmented with AI, this methodology can:

• Automate consistency checks: AI can quickly identify discrepancies across various model views.
• Analyze complex requirements: Helping engineers understand implications and potential conflicts.
• Suggest design patterns: Speeding up the modeling process for common EV architectures.

This blend dramatically enhances efficiency, reduces manual effort, and improves the quality of models, allowing engineers to tackle the ever-increasing complexity of modern EVs more effectively.

Conclusion​

The success of MBSE in the automotive and EV sector hinges directly on the methodology adopted. It’s not just about drawing diagrams; it’s about establishing a systematic, repeatable process that guides your team in building smarter, safer, and more efficient vehicles. What methodologies have you found most effective in your MBSE journey? Share your thoughts below! We're here to keep simplifying systems for smarter EVs.

Welcome to MBSE Explained, where we demystify Model-Based Systems Engineering for the automotive and EV industry. With nearly five years as a Model-Based Embedded Software Developer and Architect, and 1.5 years as a Model-Based Systems Architect in automotive projects, I've seen firsthand how crucial integrated tools are for successful system development. Today, we're diving into the powerful ecosystem of MathWorks tools for MBSE, specifically how they enable a streamlined workflow from concept to validation, focusing on System Composer, Requirements Toolbox, and their connection to system test and software Model-Based Design (MBD).

The Integrated MathWorks MBSE Ecosystem​

Developing complex automotive and EV systems demands a robust approach to managing requirements, architecture, and design. MathWorks provides a comprehensive suite of tools that supports the entire MBSE lifecycle, ensuring traceability and consistency across domains.

At the heart of this workflow is System Composer™. This powerful tool allows you to define, analyze, and specify system and software architectures using industry standards. You can model everything from high-level system components like an EV powertrain management unit to detailed sensor-actuator interfaces. System Composer acts as the central hub, enabling early-stage analysis and architectural exploration, which is critical for identifying potential issues before costly hardware is built.

Complementing System Composer is the Requirements Toolbox™. This tool allows engineers to capture, manage, and link requirements directly to system models, design components, and test cases. This direct traceability is invaluable for demonstrating compliance with standards like ISO 26262 and ensuring that every system function, from regenerative braking to battery thermal management, can be traced back to a specific stakeholder need. This integration ensures a robust "digital thread" throughout your development process.

Bridging MBSE to System Test and Software MBD​

One of the greatest strengths of the MathWorks ecosystem is its seamless integration with downstream activities, accelerating both system verification and software development.

Connecting to System Test​

The architectural models created in System Composer, combined with detailed requirements managed in Requirements Toolbox, form a solid foundation for system testing. Test engineers can leverage these models to:

• Derive Test Cases: Automatically generate test cases that directly validate specific requirements and architectural behaviors.
• Validate System Behavior: Use simulation models (often built in Simulink® and Simscape™ from the System Composer architecture) to execute tests and verify the system's performance under various operating conditions – think charging cycles for an EV battery or torque vectoring for traction control.
• Traceability for Compliance: Maintain a clear link from test results back to specific requirements, essential for regulatory compliance and audit trails in the automotive sector.

Seamless Software Model-Based Design (MBD)​

For software MBD, the transition from system architecture to detailed software design is remarkably smooth.

• Refined Design: Components defined in System Composer can be further elaborated into detailed Simulink and Stateflow® models for embedded software. This ensures a consistent design methodology from the system level down to individual software components.
• Code Generation: With tools like Embedded Coder®, engineers can automatically generate production-ready code directly from these detailed models, significantly reducing manual coding errors and development time.
• Verification and Validation: Integrated tools like Polyspace® support static code analysis and formal verification, ensuring the generated code meets quality and safety standards, which is paramount in safety-critical automotive applications.

This integrated workflow empowers teams to develop safer, more reliable, and innovative EV systems faster, by fostering collaboration and maintaining a consistent digital representation of the system throughout its lifecycle.

Conclusion​

Leveraging MathWorks tools for MBSE provides an unparalleled advantage in the complex world of automotive and EV development. From defining robust system architectures with System Composer to linking requirements with Requirements Toolbox, and then seamlessly transitioning to system testing and software MBD, the entire process is streamlined and traceable. This holistic approach empowers engineering teams to tackle the intricate challenges of modern vehicle design with confidence and efficiency.

What are your experiences with MathWorks tools in your MBSE journey? Share your thoughts below! At MBSE Explained, we're committed to simplifying systems for smarter EVs.

Welcome to MBSE Explained, where we unravel the complexities of Model-Based Systems Engineering (MBSE) for the automotive world. With a deep dive into system design, today we’re tackling a key debate: Functional (Feature) vs. Object-Oriented Approach. Whether you’re crafting an EV powertrain or optimizing a converter system, choosing the right design method can make or break your project. Let’s explore why this comparison matters and which approach comes out on top.

Why Compare These Approaches?​

In MBSE, how we structure our models shapes everything—from requirements to validation. The Functional (Feature) Approach breaks systems into actionable features, while the Object-Oriented Approach focuses on objects and their interactions. In the fast-paced automotive industry, where EVs demand both innovation and reliability, understanding these methods helps engineers align tools like SysML with project goals. This comparison isn’t just theoretical—it’s about picking the best fit for real-world challenges like battery management or CAN bus integration.

Functional (Feature) Approach: Pros and Cons​

Pros​

• Rapid Prototyping: Focuses on delivering features (e.g., regenerative braking) early, speeding up feedback loops in agile EV development.
• User-Centric: Prioritizes end-user needs, making it ideal for validating specific functions like charging efficiency.
• Flexibility: Adapts easily to changing requirements, a must in dynamic automotive projects.

Cons​

• Integration Risks: Feature silos can lead to inconsistencies when merging models (e.g., mismatched converter interfaces).
• Scalability Issues: As systems grow, managing feature overlap becomes complex, especially in large EV architectures.
• Less Structure: Lacks a unified system view, which can confuse teams during validation.

Object-Oriented Approach: Pros and Cons​

Pros​

• Unified Architecture: Models objects (e.g., battery, motor) and their relationships, ensuring a cohesive system design.
• Traceability: Excels at linking requirements to objects, critical for ISO 26262 compliance in automotive safety.
• Reusability: Object models (e.g., SysML blocks) can be reused across projects, boosting efficiency.

Cons​

• Slower Start: Building a robust object structure delays feature delivery, challenging tight EV timelines.
• Complexity Overhead: Detailed object interactions can overwhelm teams new to MBSE.
• Rigidity: Less adaptable to rapid requirement shifts compared to feature-driven methods.

The Winner: A Hybrid Approach​

So, which wins? Neither approach reigns supreme alone. For MBSE in automotive engineering, a hybrid approach takes the crown. Start with the Object-Oriented Approach to establish a solid foundation—defining objects like an EV’s powertrain components ensures structural integrity. Then, layer in the Functional (Feature) Approach to iterate on features like energy optimization, leveraging its agility. This blend maximizes traceability and adaptability, proven effective in projects like EV converter design where both system coherence and rapid validation are non-negotiable.

Final Thoughts​

At MBSE Explained, we’re committed to simplifying systems for smarter EVs. Whether you lean toward objects or features, a hybrid strategy unlocks the best of both worlds. What’s your take on this debate? Share your experiences below—let’s keep the conversation going!

Top 8 things to avoid when starting with Model Based Systems Engineering (MBSE) in Automotive.