SDV: Development Is Fast - The Problem Is Proof

Engineers in automotive software development today are caught between two worlds. On one side is a world centered around Git and IDEs, where code is committed dozens of times a day. On the other is a world driven by DOORS, Polarion, hundreds of pages of documentation, and audit preparation. Max Pabinger of useblocks sees this gap not as a tooling issue, but as a paradigm problem. Engineers are already moving fast. They just lack the structures to prove that what they build is safe and compliant - the proof system remains rooted in the past.  
 




I would first like to ask about the starting point of useblocks. Automotive software development has long been centered around tools such as DOORS, Polarion, Teamcenter, and Codebeamer. In that environment, useblocks seems to propose a somewhat different approach. What was the biggest problem or limitation that you observed in the existing PLM/ALM-centered development model? And what made you feel that “this really needs to change”? 
Pabinger        useblocks started with a  concrete problem. We were an engineers-only team on a BMW project, developing under ISO 26262 - which means traceability is not optional, it is a hard requirement. We needed to show, at every point, that our code traced back to a requirement, and that requirement traced back to a safety goal. That is when we realized that the existing toolchain was not suitable to the developer's way of working.
DOORS, Polarion, Codebeamer are great tools for requirements engineers. A world where requirements lived in centralized databases, change cycles were measured in months, and a dedicated tool administrator mediated between engineers and the system.
But they were not designed for engineers and a world with fast moving software we currently see within SDV. The engineers we worked with lived in IDEs and Git. They committed code dozens of times a day. The gap between how they worked and how the compliance tools expected them to work was a structural blocker.
Requirements were drifting from code. Version histories were disconnected from the artifacts they were supposed to govern. And because everything lived in separate, proprietary systems, there was no way to automate the compliance checks that modern CI/CD pipelines demand. Every audit became an archaeological excavation - teams spending weeks reconstructing traceability evidence for work that had happened months earlier. No integration, no automation, no shared truth.
The moment of clarity came when we saw that the fix was not a better database - it was a different paradigm entirely. Bring the artifacts into the code. Store requirements, specifications, test cases, and architecture decisions as structured text, version-controlled alongside the source in Git, processed through the same pipelines. Make traceability a natural output of the engineering workflow, not a parallel administrative burden.
That insight became Sphinx-Needs. And what has kept us going is a conviction that Clay Nelson articulated perfectly at GitHub Shift event: "You're already fast. You just can't prove it." The industry does not have a speed problem. It has a proof problem. Engineers are moving fast - they just cannot demonstrate that what they built is safe, traceable, and compliant. That is exactly the gap we exist to close.




In today’s automotive software development environment, where do engineers actually spend most of their time and energy? There are many aspects involved: requirements management, certification, regulatory compliance, cross-team collaboration, and more. From your perspective, what tasks repeatedly consume the most time in a typical engineering workflow?
Pabinger        The pattern we see constantly is this: your most experienced engineer - the one who holds the full picture of the project in their head - is not designing systems. They are manually walking traceability graphs before a review, reconstructing compliance evidence before an audit, figuring out which requirements are affected when a regulation changes.
That is expensive in two ways. First, the obvious one: it takes weeks of senior engineering time that produces no new functionality. Second, and more dangerous: the knowledge of why the system is complete lives in that person's head, not in the system. When they move to another project, you do the work again - slower, with less confidence.
The rest of the overhead is coordination. Safety teams, cybersecurity teams, and development teams each work in separate tools with no shared representation. A change in one domain triggers manual meetings across all of them just to establish who is affected. It is not that the engineers are slow. It is that the tooling forces them to work that way.


Whether it is safety, environmental regulation, or compliance in general, traceability seems to be particularly important in the automotive industry. In automotive development, traceability between requirements → design → code → test → certification is strongly emphasized. Why do you think such extensive traceability is required in automotive compared to other software industries? Among safety, liability, and regulation, which factor do you think plays the biggest role? And how does this requirement influence development environments and development practices?
Pabinger        Traceability matters in any domain where software can kill people (aerospace, medical, robotics, automotive). The underlying logic is the same: when failure is fatal, you must demonstrate at any point that you understood the risks and took every reasonable step to mitigate them.
Of the three factors, safety is the foundational driver. Liability and regulation are the mechanisms society uses to enforce safety standards - consequences of the imperative, not the cause. If you treat traceability as a compliance exercise, you get documentation that satisfies auditors but does not make the system safer. If you start from a genuine commitment to safety, traceability becomes a tool for understanding your own system - not just proving it to others.
What I find interesting is that this question - can you prove it? - is actually the same question across security, safety, and quality. In security: can you prove there is no exploitable path? In safety: can you prove every requirement is covered? In quality: can you prove your process is complete? Three domains, one question. And in all three, the answer today is usually: not without doing the work again by hand. The knowledge of why the system is complete lives in a person's head, not in the system. In security, we call that a single point of failure. That framing shaped everything we built.
Our goal at useblocks is to close that gap - reduce the administrative burden of safety-critical development without reducing the rigor. Make compliance a natural outcome of good engineering, not a parallel activity layered on top of it.






As ADAS and autonomous driving technologies evolve, automotive software is becoming increasingly complex. With this complexity, processes such as requirements management, testing, certification, validation, updates, and traceability seem to become even more critical. What new standards or expectations do ADAS and autonomous technologies introduce for automotive software development practices?
Pabinger        The real shift for me was SDV - not just increased complexity, but a fundamental change in who must collaborate and at what pace. Traditional vehicle programs were more isolated with their own toolchains and release cycles. SDV breaks that. A single software update now touches multiple domains simultaneously. Over-the-air delivery means the vehicle in the field is no longer a fixed system.
The consequence is that data silos are killing productivity and collaboration between partners. If your requirements, test, and development teams each work in separate tools with no shared representation of the system, coordination becomes the bottleneck - not compute power, not developer skill. And ADAS adds an entirely new class of requirements - probabilistic behavior, scenario coverage, AI model governance - that traditional V-model structures simply were not designed to handle.


 
From my understanding, useblocks aims to create clearer connections between requirements, documents, tests, and code, making the development process more transparent. From the perspective of a non-expert like myself: How does useblocks address these problems in actual development environments? For example, does your approach aim to replace existing tools, connect them, or introduce a new workflow such as a Git-based engineering model?
Pabinger        The core idea is what we call X-as-Code: all engineering artifacts - requirements, specs, test cases, architecture decisions - stored as structured text alongside the source code, version-controlled in Git, and processed through the same CI/CD pipelines as the code itself. Text-first, schema-aware, versioned, attributable. The artifact carries not just what was built, but why it exists, what requirement it satisfies, and what regulation it traces to.
In practice, an engineer opens their IDE, sees requirements linked to the function they are working on, makes a change, and traceability updates automatically as part of the commit. No separate tool to log into. No manual sync step.
We are not trying to replace DOORS or Polarion - we integrate with them. But we shift the primary workspace into the developer's environment. Compliance becomes a byproduct of writing code, not a separate administrative layer on top of it. Our open-source foundation Sphinx-Needs has over 300,000 monthly downloads - the community validation that this approach works is real.


 


The automotive industry has long relied on document-driven development models, while the broader software industry has moved toward Git and DevOps-based workflows. With the rise of SDV, interest in these approaches seems to be increasing in the automotive industry as well. Do you think automotive development will eventually move closer to DevOps-style workflows? Or do safety regulations and certification requirements mean that automotive will maintain a fundamentally different development model? 
Pabinger        The direction is already determined - the question is only how long the transition takes. Vehicles are now software platforms. The engineers building them come from an industry where Git is the default and CI/CD is the baseline.
There is one more force accelerating this transition massively: AI. And here is the part that most people miss. Having all engineering artifacts as structured, traceable text inside the repository is not just good practice - it is the perfect infrastructure for AI agents. When requirements, specifications, and test cases are machine-readable and linked, you can give an agent the full context of why a piece of code exists, what regulation it traces to, and what constraints it must satisfy. That is how you deploy AI in a safety-critical environment with real guard rails - not by bolting a chat interface onto a word document, but by making the artifact graph the foundation the agent reasons over.
That is exactly what we are building toward at useblocks. And the momentum is real - the collaboration with Microsoft and GitHub is bringing enormous visibility to this space. When those organisations are pointing at text-based, traceable engineering as the right foundation for AI-assisted development, it validates the direction and accelerates adoption across the industry in a way that would have taken years otherwise.


 
useblocks has been actively involved in the Eclipse SDV community. Which projects are you currently participating in, and what are your goals within those initiatives? Within the Eclipse SDV ecosystem, what kind of role do you see useblocks playing, and what kind of consensus or shared vision is emerging among participants?
Pabinger        We currently participate actively in the S-CORE project, but the reach goes beyond that - open-source projects within Eclipse SDV such as OpenBSW are already using our toolchain in practice.
We see useblocks as the traceability and compliance layer of the SDV toolchain. As shared middleware platforms like S-CORE mature, the question of how you manage requirements, validate safety properties, and produce audit evidence across a multi-contributor codebase becomes central. That is precisely our problem space. One of the core values for us is the visibility this creates: as people look at where toolchains are heading, they see traceability and compliance as a foundational layer - and they see our solutions there.
The shared conviction emerging in the community is that pre-competitive collaboration on non-differentiating infrastructure is a net positive for everyone. No OEM gains competitive advantage from a proprietary requirements format. Differentiation happens at the experience layer. Open traceability standards make the whole ecosystem faster - and safer.


The automotive software tooling market already includes very large companies. Despite this, useblocks appears to be quite unique and specialized. What do you believe differentiates useblocks most strongly from these established players? And why do you think companies with this kind of approach have been relatively rare until now?
Pabinger        The established players have built mature, capable tools - and they serve real needs. The difference is in the starting point. Those tools were designed around centralized databases and dedicated tool administrators. Our starting point was the engineer: their IDE, their Git workflow, their CI/CD pipeline.
That developer-first philosophy shapes everything. When compliance lives in the same environment where engineers actually work, they use it naturally - which means the data stays current and the traceability is real, not assembled retrospectively before an audit. Our open-source foundation Sphinx-Needs, with over 300,000 monthly downloads, reflects that this resonates broadly across the community.
The second differentiator is AI readiness. Because our artifacts are structured, machine-readable text versioned in Git, they are well-suited to AI-assisted workflows. An agent working in this environment can read a requirement, follow its regulatory trace, check links to specifications and tests, and propose changes with full context - all within the workflow the engineer already uses. That kind of safe, context-aware assistance is a natural fit for how we have structured the toolchain from the start.
As for why this kind of approach has been rare: selling into automotive procurement as a small company is genuinely hard. Long cycles, demanding qualification requirements, deep incumbent relationships. We have learned that firsthand.






Recently, many automotive companies are trying to accelerate software development. At the same time, requirements such as traceability, certification, and regulatory compliance can appear to slow down development. Do you think it is possible to achieve both faster development and strict regulatory compliance at the same time? What changes do you think the industry must make first in order to balance these two priorities? 
Pabinger        Yes - and the urgency is real. Established automotive players are under pressure to match the development pace of Chinese competitors who are shipping software at a speed the traditional industry has never seen. The answer cannot be to lower safety standards. It has to be to make compliance faster. And that starts with recognising that the industry does not have a speed problem - it has a proof problem. Teams are already moving fast. They just cannot demonstrate, continuously and automatically, that what they built is safe and compliant.
Yes. When traceability is maintained continuously - every commit updating artifact links, CI/CD pipelines enforcing coverage checks, compliance status visible in real time - the audit sprint disappears. Instead of weeks spent reconstructing evidence, you have a continuously updated evidence chain as a natural output of the engineering workflow. Speed and rigour stop being in tension because they share the same foundation.
What the industry needs to change is tooling and the willingness to commit to that change. That means moving away from compliance as an end-of-cycle activity and investing in toolchains where traceability is structural, not manual. That requires bold decisions - rethinking how artifacts are stored, how pipelines are structured, and how compliance evidence is generated. The technology to do this exists. The harder part is the organisational shift to actually use it.


Korea has a strong automotive industry ecosystem, including companies such as Hyundai Motor Group, Samsung, LG, and many Tier-1 suppliers. How does useblocks view the Korean automotive industry? What is your impression of how Korean companies are approaching software development and transformation? Do you see potential opportunities for collaboration with Korean companies?
Pabinger        Korea's automotive ecosystem is one of the most impressive in the world. The combination of OEM ambition, semiconductor leadership, consumer electronics expertise, and Tier 1 precision manufacturing is a unique strength few countries can match.
From what we observe, Korean companies have the urgency and technical sophistication to lead in the SDV transition. The challenges are the same as globally - bridging traditional automotive engineering culture with modern software practices, managing multi-supplier complexity, producing compliance evidence at SDV delivery pace. Korean engineering teams are methodical and quality-focused - exactly where our tooling creates the most value. We are very open to deeper collaboration.

AEM(오토모티브일렉트로닉스매거진)

---