The complexity of modern automotive systems is unprecedented. Vehicles today integrate mechanical components, electronics, and software into tightly coupled cyber-physical systems. This evolution challenges traditional development methods, which often rely on discipline-specific processes and document-based workflows. These approaches struggle to maintain consistency, traceability, and collaboration across domains, especially under the pressure of safety and quality standards such as ISO 26262 and ASPICE. 

To address these challenges, BMW and FEV.io collaborated on the development of SMArDT, the Specifications Method for Requirements, Design, and Test. Rather than introducing a new process model, SMArDT provides a structured modeling framework that supports diverse development approaches while ensuring consistency and traceability across all technical disciplines. 

Why SMArDT Was Needed 

The motivation for SMArDT arose from practical pain points in system development. Document-centric workflows made it difficult to maintain alignment between requirements, architecture, and implementation. When multiple teams work in parallel, such as software, electronics, and mechanics, information gaps and inconsistencies are almost inevitable. These gaps complicate safety verification and increase the risk of costly rework. 

SMArDT addresses these issues by establishing a shared system model as the central reference point. This model integrates requirements, design decisions and specifications across viewpoints, enabling engineers to trace relationships from stakeholder needs down to technical implementation. The approach is not about replacing existing processes but about providing a common modeling language and methodology that supports them. 

The Method in Detail 

SMArDT structures system development into four interconnected viewpoints, each representing a different level of abstraction: 

1. Context Viewpoint 
   Defines system boundaries, interactions, and stakeholder requirements. It uses context and use-case diagrams to capture what the system is expected to do and how it interacts with its environment. 

2. Functional Viewpoint 
   Describes the functional concept, breaking down system behavior into functions and sub-functions. These functions are derived from system requirements and refined until they reach elemental granularity. 

3. Logical Viewpoint 
   Translates functions into principle solutions and logical architecture. This layer defines how the system achieves its behavior using logical and physical effects, grouping them into coherent structures. 

4. Technical Viewpoint 
   Details the technical architecture across hardware and software domains. It includes E/E components, software modules, and mechanical elements, all linked back to logical and functional requirements. 

SMArDT applies its four viewpoints consistently across all levels of hierarchical system decomposition. Each system level, from the overall vehicle down to subsystems and components, is modeled using the same structure. This approach ensures that relationships between requirements, functions, and technical elements remain traceable not only within a single level but also across levels. This hierarchical modeling is essential for managing complexity and enabling reuse of architectural patterns in future projects. The traceability across all viewpoints and system levels is further essential for compliance with ISO 26262 and ASPICE. 

For modelling the viewpoints, two standard approaches can be used: 

• Top-Down: Starting with high-level context and functional models, suitable for defining new concepts and developing new systems 

• Bottom-Up: Beginning with detailed technical descriptions, useful when existing implementations need to be captured. 

In practice though, a hybrid approach proved to be most effective. Engineers initially transferred available information into the model without strict order, then structured and refined it iteratively either bottom up or top down.

 

Introducing SMArDT in Practice 

The method was not rolled out in a single step; instead, it was introduced step by step within ongoing development processes. This approach provided valuable insights into how MBSE can be integrated into real-world development environments. 

Unlike prescriptive process models, SMArDT does not dictate the order in which the viewpoints must be developed. This flexibility allows teams to adapt the method to different project contexts, whether starting from high-level concepts or capturing existing implementations. These models replace traditional documentation and expand organically as more teams contribute. This incremental approach reduces resistance and demonstrates value early. 

Governance and Consistency 

Flexibility is important, but without clear modeling rules, complexity can escalate quickly. BMW established a model governance framework covering naming conventions, traceability, and structural integrity. Regular reviews and Q&A sessions supported consistency and helped resolve issues early. 

A Practical Example 

One case involved modeling a safety-critical function with significant interaction across hardware and software. Existing documentation was fragmented, making it difficult to verify signal flows for safety analysis. 

Using SMArDT, engineers created new diagrams in the Context and Functional viewpoints to capture requirements and behavior. They then extracted relevant hardware and software elements into the Technical viewpoint and linked them to logical abstractions. 

This exercise revealed gaps in detail and inconsistencies between sources, issues that were flagged and resolved collaboratively. The result was a coherent, traceable model that supported safety verification and could be reused for future functions. 

Key Lessons Learned 

The introduction of SMArDT highlighted several important lessons for MBSE adoption: 

• User-Centric Development: Involving engineers in method design ensures relevance and acceptance. 

• Incremental Integration: Small, usable models encourage adoption and reduce disruption. 

• Governance is Essential: Clear rules and oversight maintain consistency as models grow. 

• Flexibility Matters: Supporting both top-down and bottom-up approaches accommodates diverse project needs. 

Looking Ahead 

As adoption expands, the challenge will shift from agile adaptation to stability. Early phases allow frequent adjustments, but broader rollout requires a more standardized approach. The ultimate goal is a method that supports collaboration across disciplines while remaining robust enough for large-scale use. 

Publication 

Further insides about SMArDT, its development and introduction can be found in the paper with the title “Erfahrungen aus der anwendernahen Entwicklung des ganzheitlichen disziplinübergreifenden MBSE-Ansatzes SMArDT“, published in the conference proceedings of the TdSE (Tag des Systems Engineerings).