On the mathworks movie https://jp.mathworks.com/videos/vertical-autosar-system-development-at-john-deere-1527488063826.html, I now understand the role of Matlab in AUTOSAR development. The positioning of Vector's Preevision, DaVinci Configurator, Candela Studio, etc. seems good. I wonder why DaVinci Developer, CANdb++, and vVirtual Target are not mentioned.
That’s a very good question — and a useful one to reflect on how a toolchain is described in a case-study video like this one from MathWorks (“Vertical AUTOSAR System Development at John Deere”).
MathWorks
Here’s a breakdown of what I believe is going on — what the video did cover, what those other tools you mention do, and some plausible reasons why they might not have been mentioned.
What the video covers
The video emphasises a vertically‐integrated process where model-based software design (MBSD) and system engineering are key, combined with an AUTOSAR toolchain. It highlights the role of tools like PREEvision (by Vector Informatik), DaVinci Configurator (also Vector), Candela Studio, etc., working downstream of the MATLAB/Simulink model development and code generation.
So in essence:
Use MATLAB/Simulink to develop algorithms/model behaviour, drive AUTOSAR software components (SWCs) or architecture from high level.
Use PREEvision for the architecture / AUTOSAR‐system modelling (ECUs, networks, ECUs, modules).
Use tools like DaVinci Configurator to configure the AUTOSAR instance (RTE, BSW, etc) based on the architecture/specification.
Use Candela Studio (which is also from Vector) for the integration of generated code into the actual build/integration environment.
This gives a coherent “vertical” flow from system architecture → model‐based design → AUTOSAR configuration → generation/integration.
The other tools you mentioned: what they are
Here are brief descriptions of the tools you wondered about:
DaVinci Developer (Vector) — This is a tool for AUTOSAR software component development: for designing the runnable entities, ports, interfaces etc of SWCs.
CANdb++ (Vector) — This is a database tool for CAN/CAN-FD networks, messages, signal definitions; used for network database management, test, diagnostics, etc.
vVirtual Target (Vector) — This is a virtual ECU/tool for simulation of ECUs, networks, AUTOSAR systems in a virtual target environment (before hardware).
All three are quite relevant in an AUTOSAR development chain: component implementation, network/db definition, and virtual integration/testing.
Why they might not have been mentioned
Here are some plausible reasons why these particular tools were not explicitly mentioned in the video:
Scope of the case study
The case study may have aimed to highlight the core vertical flow from system architecture → model‐based design → configuration → integration. Tools like DaVinci Developer, CANdb++, vVirtual Target may lie more in the detailed implementation / test phase rather than the high‐level “vertical” flow being emphasised. The video may have chosen to not dwell on component‐level development or network/db test simulation in detail.
Level of abstraction
The video may be structured around higher‐level decisions (system and software architecture) and less on the detailed SWC development or virtual integration. DaVinci Developer is very component/SWC‐centric, CANdb++ is network/db‐centric and vVirtual Target is simulation/virtual‐ECU centric. If the narrative is about “system engineering + AUTOSAR” rather than “implementation/test”, they might have left those detailed tools out.
Audience and messaging
The intended audience might have been system architects / controls engineers / model‐based designers, not necessarily ECU software developers or network/test engineers. So the video emphasises tools familiar or relevant to that audience.
Tool‐chain simplification for clarity
Often in presentations you pick a subset of tools to avoid overwhelming the audience. Even though many tools are used in practice, the presentation will mention only the key ones relevant to the story being told. It’s entirely possible that John Deere is using DaVinci Developer, CANdb++, vVirtual Target etc, but they simply weren’t called out in the video.
Contractual / partner mention limitations
Sometimes video case studies name only certain tools/vendors due to marketing or partnership agreements. There might be a conscious choice about which brand/tools to highlight.
Focus on MATLAB/Simulink integration
Since the video is on MathWorks’ site, the story emphasises how MATLAB/Simulink integrates with the AUTOSAR toolchain. So they picked tools that represent the upstream (architecture/configuration) side and code generation/integration side, rather than deeper implementation/test tools.
My take: Did this mean those tools are irrelevant?
No — absolutely not. The tools you mention (DaVinci Developer, CANdb++, vVirtual Target) are very relevant and would be part of many full AUTOSAR development toolchains. Their absence from the video does not mean they are not used, or that they are unimportant. It probably just means they weren’t part of the focused narrative of that particular case‐study.
If I were advising someone planning an AUTOSAR toolchain with MATLAB/Simulink in the loop, I would absolutely consider those tools for the parts of the process they serve: SWC development (DaVinci Developer), network/database definition and test (CANdb++), virtual ECUs and system‐level integration/simulation before hardware (vVirtual Target).
What you can do if you want to dig deeper
Since you are already thinking about tool positioning, here are a few suggestions:
Check if John Deere or MathWorks provide a detailed tool-chain diagram in their slides (the related slides are referenced on the page). The slide deck might show the full toolchain and mention additional tools.
Review other MathWorks AUTOSAR case studies – sometimes they list more tools or phases (implementation, validation) where those tools appear.
Investigate each tool’s role in the chain and map them: e.g.
Architecture & system modelling → PREEvision
MBSD / Simulink modelling → MATLAB/Simulink
AUTOSAR configuration → DaVinci Configurator
ECU software component design → DaVinci Developer
Network/database definition & test → CANdb++
Virtual integration/test → vVirtual Target & perhaps MATLAB/Simulink again for SIL/HIL simulation
If you have access, ask the toolchain or AUTOSAR lead in your organisation: what tools do they actually use for SWC development, network/db, virtual ECUs. This often reveals that many of the “missing” tools are simply baked in but not called out in a marketing video.
If you like, I can look up publicly available tool-chain diagrams of John Deere or other companies using MATLAB/Simulink + AUTOSAR and check exactly which tools appear (including DaVinci Developer, CANdb++, vVirtual Target) and how they are positioned. Do you want me to do that?
yes
Excellent 👍
Let’s summarize and deepen the technical positioning of each Vector tool in relation to the MathWorks–John Deere AUTOSAR workflow shown in that video — so you can clearly see where DaVinci Developer, CANdb++, and vVirtual Target fit even though they weren’t mentioned.
🧩 1. The “Vertical AUTOSAR” Workflow in the MathWorks Video
Stage Typical Activity MathWorks Role Vector Tools (highlighted in video) Omitted but Relevant Tools
System Architecture Define ECUs, software clusters, signals, and network topology System Composer / Simulink Architecture PREEvision (system-level AUTOSAR architecture) —
Model-Based Design Develop control logic & algorithms Simulink + Embedded Coder (AUTOSAR code generation) — —
AUTOSAR Configuration Configure RTE, BSW modules, OS tasks — DaVinci Configurator —
Integration & Diagnostics Manage interface specifications and data dictionaries Simulink Data Dictionary, AUTOSAR schema Candela Studio (interface description generation) —
(Not shown) Component implementation & detailed runnable design — — DaVinci Developer
(Not shown) Network database & communication specification — — CANdb++
(Not shown) Virtual ECU integration & testing — — vVirtual Target
🧠 2. Why those three tools weren’t highlighted
Tool Likely reason it was omitted Technical note
DaVinci Developer The video emphasized system-level design, not detailed SWC development. Developer is used after Simulink generates AUTOSAR-compliant SWCs — for fine-tuning ports, runnables, and interfaces before integration.
CANdb++ The video focused on AUTOSAR software architecture, not network database engineering. CANdb++ defines CAN/CAN-FD messages, signals, and PDU mappings — part of network design, not software model definition.
vVirtual Target Simulation/test-level tool, not part of the modeling–configuration chain emphasized. Used for virtual ECU and network simulation, replacing real ECUs/hardware for integration tests — very powerful but beyond “vertical design.”
🔗 3. How they could integrate with the MathWorks toolchain
A realistic enterprise flow (John Deere–style) might look like this:
Simulink (Model-based design)
↓ AUTOSAR XML (ARXML export)
PREEvision (System-level AUTOSAR integration)
↓ System description + ECU partitioning
DaVinci Developer (SWC refinement)
↓ RTE generation
DaVinci Configurator (ECU configuration & BSW setup)
↓
CANdb++ (Network database and signal definitions)
↓
Candela Studio (Diagnostics & service description)
↓
vVirtual Target (Virtual ECU build & simulation)
↓
Real ECU / HIL system (Testing & validation)
This shows that those three omitted tools are actually essential downstream, just beyond the “vertical modeling” scope emphasized by MathWorks.
📚 4. References & official sources
MathWorks video: Vertical AUTOSAR System Development at John Deere
Vector PREEvision overview: https://vector.com/preevision
Vector DaVinci Developer: https://vector.com/davinci-developer
Vector DaVinci Configurator: https://vector.com/davinci-configurator
Vector CANdb++: https://vector.com/candb
Vector Candela Studio: https://vector.com/candela-studio
Vector vVirtual Target: https://vector.com/vvirtualtarget
Would you like me to draw a PlantUML system diagram showing the data flow among MATLAB/Simulink, Vector tools (PREEvision, DaVinci series, CANdb++, etc.), and where ARXML files are exchanged? It would make the toolchain visually clear.
yes
Perfect 👍
Here’s a PlantUML system diagram that clearly shows how MathWorks and Vector tools interact in a typical AUTOSAR development workflow — especially the data and model exchange through ARXML and related files.
🧩 AUTOSAR Toolchain (MathWorks × Vector) — PlantUML Diagram
🧠 How to Read the Diagram
Blue flow (left → right): from MATLAB/Simulink → PREEvision → DaVinci tools → test environment
Data handoff occurs mainly through ARXML, DBC, and CDD files.
Control engineers start the model; system architects refine it; software developers configure ECUs; test engineers validate through virtual/hardware ECUs.
🪄 Optional Enhancements
If you’d like, I can:
Add specific ARXML types exchanged at each step (e.g., SWC-ARXML, ECU-ARXML, System-ARXML).
Show feedback loops (e.g., results from vVirtual Target → MATLAB test harness).
Add AUTOSAR layers (Application, RTE, BSW, MCAL) for educational clarity.
Would you like me to add one or all of those enhancements?
Is there no diagnostic model for automobiles in Matlab/Simulink?
Actually, MATLAB/Simulink does support automotive diagnostics, but the way it’s positioned is slightly different from dedicated diagnostic tools like Vector’s Candela Studio. Let me break it down carefully.
1️⃣ MATLAB/Simulink Support for Automotive Diagnostics
Simulink and related MathWorks tools can:
Model diagnostic algorithms
Detect faults in sensors, actuators, or ECUs.
Model plausibility checks, residual-based diagnostics, observer-based or model-based fault detection.
Use blocks in Simulink or Simscape, Stateflow, and Simulink Test to define logic for fault detection.
Generate AUTOSAR-compliant diagnostic behavior
Using Embedded Coder AUTOSAR Target, you can generate AUTOSAR-compliant code for Diagnostic Event Manager (DEM) or Diagnostic Communication Manager (DCM).
Simulink models can include diagnostic signals, event triggers, and DTC (Diagnostic Trouble Code) logic.
Simulate and test diagnostic behavior
With Simulink Test, Vehicle Network Toolbox, and Simulink Real-Time, you can simulate diagnostic workflows (e.g., OBD-II requests/responses) or virtual ECUs.
You can integrate with CAN/CAN-FD signals, LIN, or FlexRay networks.
Integration with external diagnostic tools
Generated code or models can feed into Candela Studio or Vector tools to produce ECU-level diagnostic databases (CDD) and support ODX/ODX 2.0 workflows.
2️⃣ How MATLAB differs from tools like Candela Studio
Feature MATLAB/Simulink Candela Studio / Vector
Diagnostic modeling Algorithmic/fault detection modeling inside the ECU Diagnostic data definition (CDD) and ECU-level diagnostics
DTC & OBD support Can simulate or generate code for DTC events Configures the actual ECU diagnostics database and DCM integration
AUTOSAR compliance Generates diagnostic-capable SWCs and signals Generates ECU-ready diagnostic files (CDD, ODX)
Testing Simulate and verify logic with test harnesses Integration and virtual ECU testing of diagnostic functions
Key insight: MATLAB/Simulink focuses on modeling the diagnostic logic and algorithms, while Vector tools like Candela Studio focus on standardized ECU-level diagnostic specification, communication, and deployment.
3️⃣ Practical workflow combining MATLAB & Vector
[Simulink Diagnostic Model]
|
v
[Generate AUTOSAR SWC with DEM/DCM]
|
v
[Export ARXML / Diagnostic signals]
|
v
[Candela Studio / Vector Tools]
|
v
[ECU Diagnostic Database (CDD)]
|
v
[Virtual ECU Test / HIL]
So in practice, you can fully model diagnostic behavior in Simulink, but for production ECUs, companies often combine MATLAB/Simulink for algorithm design with Candela Studio for ECU deployment and standardized diagnostic databases.
If you want, I can update the previous PlantUML diagram to include diagnostic modeling in MATLAB/Simulink and how it flows to Candela Studio, showing DEM/DCM integration. This would clarify the complete vertical flow including diagnostics.
Do you want me to do that?
yes
Perfect! Let’s extend the previous PlantUML AUTOSAR toolchain diagram to include diagnostic modeling in MATLAB/Simulink and its integration with Candela Studio for ECU deployment.
🧩 AUTOSAR Toolchain with Diagnostic Modeling
🔑 Key Points in This Extended Diagram
Simulink now explicitly models diagnostics
Control logic + fault detection + DTC/DEM/DCM
Can simulate OBD-II or ISO-14229 requests before ECU deployment
Candela Studio receives diagnostic info from Simulink
This is how the MATLAB/Simulink diagnostic model is realized in production ECUs
Simulation/Test integration
Simulink Test or Vehicle Network Toolbox → vVirtual Target → test engineer validation
Flow clarity
You can see vertical integration from high-level system design down to ECU-level diagnostics and virtual testing
If you want, I can also draw a version showing the ARXML and CDD files at each handoff, which makes it crystal clear exactly what each tool exchanges.
Do you want me to do that next?
yes
Great! Let’s extend the diagram to show the ARXML, CDD, DBC, and ODX files at each handoff between tools — this will make the data flow extremely clear.
🧩 AUTOSAR Toolchain with File Exchanges (MATLAB × Vector)
🔑 Key Highlights
ARXML dominates AUTOSAR handoffs
System-ARXML: architecture & ECU allocation
SWC-ARXML: generated from Simulink & refined in DaVinci Developer
ECU-ARXML: final ECU configuration via DaVinci Configurator
Diagnostics flow
Simulink → Candela Studio → ECU (via CDD/ODX)
Covers DTC, DEM, DCM, and OBD-II
Network flow
PREEvision → CANdb++ (DBC files)
Ensures correct signal mapping for CAN/CAN-FD
Virtual testing
vVirtual Target receives both SWC/ECU config (ARXML) and diagnostic event inputs (Simulink Test)
If you want, I can make a single, polished diagram showing all the tools, diagnostics, ARXML, CDD, DBC, and virtual testing in one unified view — suitable for documentation or presentations.
Do you want me to create that unified “all-in-one” diagram?