An open-source project for digitally engineered, configurable, continuously certifiable software-defined vehicle (SDV) product lines. DE4SDV applies model-based systems engineering — SysML v2, product-line engineering, digital continuity, simulation interoperability, and continuous compliance — so that SDV variability across application domains (such as ADAS, telematics, connectivity, and core vehicle software) is modeled explicitly as configurable architectures, enabling systematic comparison of alternatives, transparent trade-off decisions, and lifecycle-wide assurance.
DE4SDV is a workstream within the INCOSE Automotive Working Group.
In the SDV future, OEM differentiation will extend beyond traditional choices such as color, trim packages, sensors, and assistance systems. A central differentiator will be certified freedom: the ability to customize vehicle features within clearly defined guardrails that preserve safety, security, and compliance. Equally important are openness and trust, including transparency over how vehicle and user data is handled, and meaningful user control over that data.
DE4SDV embraces ecosystem diversity rather than locking into a single stack: across subsystems, multiple open-source alternatives already exist, and the project models that variability instead of hiding it.
The core artifact is the SysML v2 systems model under
textual-notation-of-model/. Explore
it in the live viewer:
- https://viewer.de4sdv.org — the public, read-only HTML viewer: model tree, member documentation, and every declared view with the diagram SysIDE renders from it — including hover tooltips on elements and connections, go-to-definition, branch/PR revision picking, and diagram fullscreen.
- Running it locally serves your own working tree and unmerged branches:
python -m tools.sysml_html_viewer.serve --repo . --port 8787
# open http://127.0.0.1:8787/See the model viewer how-to for every feature, or click Help / Elements in the viewer header (the guides are published on the viewer website too).
New here? The getting started guide walks you through: what DE4SDV works on, the three-system framing, repository layout, exploring the model, understanding the increment process, running the checks, and making a first contribution.
To read the model source itself, the model element guide explains the SysML v2 element kinds used across the model and why DE4SDV uses them — from the increment shell and views to the verification/evidence chain.
DE4SDV uses the ASELCM three-system framing to keep product, engineering, and ecosystem scopes distinct:
- System 1: configurable SDV product line and configured vehicle/software variants. The engineered system managed by DE4SDV: SDV vehicle architecture variants, feature configurations, product models, software and hardware alternatives, interfaces, operational behavior, and variant-specific safety, security, and compliance constraints.
- System 2: DE4SDV life-cycle engineering and assurance system. The primary repository System-of-Interest: a project-governed, open-source, model-based SDV product-line engineering and assurance management system that specifies configurable architectures, manages variability, integrates project-owned and selected external OSS assets through controlled interfaces and adapters, executes verification, validation, simulation, and digital-twin workflows, and maintains continuous-certification evidence baselines for SDV variants.
- System 3: DE4SDV open innovation ecosystem. The governance, standards, methodology, contributor, toolchain, and upstream ecosystem that evolves System 2: maintainers, contributors, ADRs, review workflows, standards communities, external OSS projects, and methodology owners.
Inside the System 2 boundary:
- Product-line architecture and variability definitions under DE4SDV governance
- Project-controlled integration assets, including adapters, wrappers, interface contracts, and baselines
- Verification, validation, simulation, and digital-twin workflow assets managed by the project
- Lifecycle evidence, metadata, and traceability artifacts needed for continuous certification claims
Outside the System 2 boundary, but connected through interfaces:
- Independently governed upstream OSS projects and external toolchains
- Partner, supplier, enterprise, or ecosystem systems not governed by DE4SDV
- Runtime or operational environments that consume System 2 outputs but are not project-controlled
Boundary rule: an element is part of System 2 only when DE4SDV governs its configuration, change control, and evidence or traceability obligations. Otherwise it is treated as an external system at the ecosystem boundary, integrated through explicit interface and assurance contracts. This boundary definition aligns the project with digital-twin reference-model practice by making the managed twin boundary explicit.
| Area | Purpose |
|---|---|
docs/ |
Human-facing documentation: getting-started, guides, terminology, ADRs, runbooks, plans |
approach/ |
Process set, framework, ontology, viewpoints |
methodologies/ |
Method guidance and reusable engineering methods |
textual-notation-of-model/ |
System model assets and examples |
model-based-product-line-engineering/ |
Feature models, configurations, shared assets, product models |
implementation/ |
Reference implementations with reproducible evidence (see implementation/README.md) |
compliance/ |
Safety, security, UNECE, homologation-related evidence placeholders |
continuous-homologation/ |
Continuous compliance and approval evidence workflow |
configuration-management/ |
Baselines, change control, versioning, release evidence |
standards/ |
Standards map and interpretation notes |
digital-continuity/ |
OSLC, digital thread, traceability, lifecycle integration |
digital-twin/ |
Digital twin concepts, parameters, and runtime alignment |
simulation/ |
FMI/FMU/SSP simulation integration assets |
sysmlv2-api/ |
SysML v2 API clients, examples, integration notes |
devsecops/ |
CI/CD, security automation, SBOM, threat-model automation |
experiments/ |
Spikes and exploration results (not maintained assets) |
tools/ |
Scripts, utilities, and development tooling |
scripts/ |
Repository checks, smoke tests, SysML validation wrapper |
tests/ |
Test suite for repository scripts and tooling |
.github/agents/ |
Task-specific AI agent instructions |
The full index lives in docs/repository-tree.md.
This project welcomes contributions beyond code: documentation, examples, safety/security analysis, modeling patterns, feature models, test cases, issue triage, and standards mapping are all valuable.
- Read the getting started guide for orientation
- Read the practical contributor guide:
CONTRIBUTING - Read
AGENTSif you use an AI coding assistant - Read the Project Charter
- Open an issue using the templates in
.github/ISSUE_TEMPLATE/ - Submit a focused pull request using the PR checklist
Use GitHub issues and pull requests for project work, questions, proposals,
and decisions that need a durable public record. DE4SDV also uses Mattermost
for lightweight coordination at https://chat.de4sdv.org (invite-only;
request an invite through the Mattermost invite request issue template).
See COMMUNICATION for the full communication policy.
Except where otherwise noted, original DE4SDV content is licensed under the
Apache License 2.0. This repository also contains third-party or
derived material under other licenses; in particular, the generated
COVESA_VSS.sysml
library is licensed under the Mozilla Public License 2.0. Per-file SPDX
identifiers and accompanying license files identify the license applicable to
such material. See NOTICE for the bundled-material summary.
- ASELCM three-system framing
- SYSMOD adoption and tailoring
- COVESA VSS as SysML v2 library
- SysML v2 API repository as live model store
See also docs/references/source-notes for detailed source attributions.

