BITS&CHIPS EVENT 2026

The characteristics of warfare are constantly evolving. In Ukraine, the use of flying drones has altered the way battles are fought. Battles are decided on the ground, so unmanned ground systems may well be the next big evolution in warfare.
It is, however, a challenging evolution. Tactical mobility is essential for military operations, and tactical mobility on the ground is harder than in the sky. In addition to this, soldiers are used to hardware that always increases capacities: more armor, more mobility, more firepower.
Developing CUGS breaks away from this trend because of both technological and human limitations. And in addition to hardware, software will become a critical factor for operational success.

In complex high-tech systems, service excellence is often perceived as an operational challenge. In reality, it’s largely determined long before a product reaches the field. Critical capabilities such as maintainability, diagnostics, upgradeability, observability and availability are rooted in early systems architecture and design decisions.
This talk explores how service requirements can be systematically integrated into product development from the very beginning. Drawing on practical examples from the semiconductor industry, it demonstrates how systems engineering can bridge the gap between product development and lifecycle support. Attendees will gain insights into architectural principles, design trade-offs and cross-functional collaboration approaches that enable superior service performance throughout the product lifecycle.
The talk highlights why service shouldn’t be treated as an afterthought, but as a core design objective that creates long-term customer value, operational excellence and sustainable business success.

Artificial intelligence is increasingly being embedded into high-tech systems, ranging from autonomous machines and robotics to manufacturing equipment, medical devices and other software-intensive products. This opens up many new opportunities, but it also brings new engineering challenges. Unlike traditional software components, AI components learn from data, deal with uncertainty and their behavior may change as models, data and operating conditions evolve.
This talk discusses what this means for the way we design and build reliable AI-enabled systems. The focus isn’t on AI as a standalone model, but on AI as part of a larger system that needs to be safe, robust, maintainable and useful in practice. The talk addresses topics such as requirements, architecture, validation, monitoring, human oversight and the collaboration needed between software engineers, data scientists, system architects and domain experts.
The main message is that successful AI-enabled systems aren’t created by better models alone. They also require careful engineering decisions, clear system boundaries, continuous evaluation and a realistic understanding of where AI creates value and where it introduces risk. The talk offers practical insights for engineers, architects and technology leaders working on the next generation of intelligent high-tech systems.

Everyone is talking about AI safety. But what if the biggest safety risk isn’t the AI?
As robotic systems leave controlled factory cells and enter the real world, every autonomous decision ultimately becomes executable C/C++ code running on embedded processors. This execution layer translates AI intent into physical action and determines how a robot behaves.
Although generally less algorithmically complex than the AI stack above it, the execution layer is often the most safety-critical. Compiler and runtime library defects can introduce latent, systematic faults that are rarely exposed through application testing alone, making trust in the execution layer a matter of objective evidence rather than assumption. Safety can’t be built on assumptions; it must be built on evidence.
This talk reveals why trustworthy toolchains are a foundation of safe AI, using real examples of compiler and library defects that silently alter system behavior. We show how software-defined products, OTA updates, open-source adoption and emerging regulations are driving the need for objective, continuous qualification evidence throughout the software lifecycle. Finally, we present an architecture that combines continuous toolchain qualification with a monitored safety envelope, enabling autonomous systems to evolve without compromising safety.
The future of safe AI depends on trustworthy execution.

AI surely is hot, and many companies are racing against each other and themselves to implement AI for any and all tasks. Success stories around increased output, more lines of code written, optimized pipelines and faster deliveries are all around the corner. One would assume AI is reshaping the Software Development Lifecycle (SDLC), and without it, you’ll miss out on engineering excellence, improved quality and efficient and streamlined developer productivity. Great!
But does this assumption hold up in the actual world? In this talk, we’ll examine whether greater productivity automatically translates into better business outcomes and what the “missing ingredient” is in the current business landscape. Using actual examples from the field, we’ll discover why adopting AI alone isn’t a shortcut to engineering excellence, what bottlenecks can be encountered and ultimately need to be considered and how to deal with pitfalls and downsides of suboptimal AI incorporation of your business and engineering processes.

The CUGS program must deliver both a combat operational capability and the innovation lifecycle needed to sustain and evolve it. For the Royal Netherlands Army, this means mastering a new discipline: continuous engineering of a complex, integrated system. The ambition is bold – updating deployed systems within days, or even hours, through an agile engineering approach. The greatest hurdles aren’t technological, but organizational: changing structures, processes and mindsets to make continuous engineering a reality.

Image-guided intervention systems must support diverse clinical procedures, customer segments and regional needs while remaining dependable through a long product lifecycle. This creates an architectural tension: Shared capabilities need stability, while procedure-specific applications and AI-enabled capabilities need to evolve at different speeds. This talk presents a platform approach for Azurion. A durable core provides the common clinical, system and safety foundations – apps that address procedure- and segment-specific workflows on a multi-year cadence. A rapidly evolving AI-enabled layer can extend those workflows through controlled integrations, without forcing changes in the core. Three architecture decisions frame the discussion: which capabilities belong in the stable platform, which should remain application-specific and when a repeated need justifies promotion into the core. Stable interfaces, compatibility rules and clear ownership let each layer evolve independently while preserving the overall system. The case offers lessons for any complex high-tech product family: A platform makes variability explicit and manageable, protecting the long-lived foundation while enabling focused innovation.

AI can generate code faster than ever before. But when it comes to legacy systems, speed alone isn’t the solution. Without architectural direction, AI can make the problem worse by producing more code, more complexity and more technical debt at a higher pace. In this talk, Robert van Uden explores why architecture remains the deciding factor in successful AI-augmented software engineering. Drawing on his experience as a software architect in the high-tech industry, he shows how AI becomes truly valuable when combined with clear architectural boundaries, strong engineering practices and deliberate validation. He also argues that AI adoption isn’t primarily a tooling challenge, but a methodological one: Success depends on structure, responsibilities and maintainable ways of working. This talk is for anyone dealing with technical debt, modernization pressure and the promise of AI. It offers a practical perspective on how to use AI to modernize legacy systems responsibly and why, in the end, architecture is what makes the difference.

Supervisory control is a key part of cyber-physical systems, enabling system resources to work together in a safe, correct and optimal way. Developing supervisory controllers by hand becomes increasingly challenging, for instance due to growing performance demands, growing system complexity, the need to support more and more variants and a shortage of skilled engineers. In contrast, with synthesis-based engineering (SBE), correct-by-construction supervisory controllers can automatically be computed from system models and requirement specifications that describe what the system should do. An automatically synthesized supervisory controller is easy to update, allows for advanced domain controllers and guarantees maximal permissiveness.
SBE has successfully been applied in industry, for example in the semiconductor domain, industrial printing and healthcare. TNO-ESI is currently also investigating the application in the fusion energy domain together with Differ, addressing challenges in supervisory-control design and exploring model-based approaches to support the development of next-generation control systems.

AI is already producing measurable results inside industrial operations – in field service, safety-critical reporting and mission-critical support. This talk is a close look at systems Proekspert has actually built and put into production for industrial and OEM clients, and what the work taught us along the way.
The anchor is one of the most tangible forces facing European industry today: an aging, retiring workforce and the decades of hands-on knowledge that leave with it. We’ll walk through a field-service copilot built to capture and pass on that expertise – what it does, how it fits into the systems teams already use and why keeping the technician in control mattered. Alongside it, two further deployments – from safety-critical and mission-critical environments – show the same engineering demands under harder constraints.
The through-line is practical, not theoretical: what these systems needed to be trusted in daily operations – grounded in the client’s own data, built onto the stack already running, with a human on the outcome. Lessons from building the work, not a framework.

How do you engineer combat unmanned ground systems while autonomous technologies, operational concepts and military tactics are changing at speed? The CUGS program combines Incose-based systems engineering with MBSE to address key technical challenges and architectural trade-offs. At its heart is an adaptable architecture designed to remain relevant in a rapidly evolving operational and technological environment.

Failure modes and effects analysis didn’t start out as a nice-to-have. It was formalized by the US military in 1949, adapted by NASA for the Apollo missions and later migrated into automotive and consumer product development. It remains one of the most rigorously proven risk mitigation tools in engineering, and yet, it’s chronically under-utilized.
Drawing on 20 years of mechanical-design leadership in deep tech across aerospace, aviation and consumer hardware, this talk makes the case for treating FMEA as a living design tool owned by engineering, not a compliance checklist completed by quality. It also asks the harder engineering ethics question: Why do rigorous, well-understood risk processes erode under schedule and cost pressure, even when everyone involved knows better?
The talk utilizes industry case studies and real incidents from the speaker’s career, including a moment where a “good enough” compromise quietly became the new lowered standard. It examines how small, individually defensible compromises accumulate into systemic failure.
This is not a call for more paperwork. It’s a look at personal and organizational conditions that let good engineers make bad decisions, and how the FMEA process can objectively safeguard against them.
Attendees will leave with a concrete framework for applying FMEA as an early, cross-functional design tool and a clearer, more honest picture of why risk processes succeed or quietly fail.

Imagine reducing hours of implementation work to a well-crafted prompt. Today’s AI development tools are no longer limited to generating snippets of code; they can create documentation, develop tests, perform basic self-validation and rapidly adapt existing applications to new requirements. These capabilities have the potential to significantly accelerate software development and lower the barrier to implementing new features.
However, as AI takes on increasingly complex reasoning tasks, a new challenge emerges. The development flow shifts from direct implementation to a cycle of prompting, waiting for reasoning, reviewing results and validating outcomes. While this can improve efficiency, it also introduces periods of reduced engagement where maintaining focus becomes more difficult. In contrast, traditional development workflows provided a more continuous and immersive experience through hands-on coding and testing.
To fully realize the benefits of AI-assisted development, we must look beyond the technical capabilities alone. Success will depend on finding a way of working that maximizes AI’s strengths while minimizing interruptions to developer focus, ensuring productivity gains translate into sustainable engineering practices.

Modernizing legacy software has always been risky, expensive and slow. Artificial intelligence has the potential to change that. But how do you use AI effectively in a migration, keeping what’s good while leaving the baggage of the past behind?
Based on the migration and redesign of a complex application, this talk walks you through a structured, technology-agnostic process for modernizing legacy software with AI. It shows how AI is applied in each phase: from reverse-engineering undocumented code and capturing the domain knowledge buried in it, to incrementally restructuring it into a modern architecture. At every step, the new system is tested against the behavior of the old, so nothing breaks silently.
AI won’t migrate your legacy system for you, but used well, it can greatly accelerate the process. Learn where it delivers, where it disappoints and where it shouldn’t be trusted, so you can keep quality firmly in human hands.

AI coding assistants make code cheap to produce. They don’t make it cheap to get a software-intensive high-tech system right. Timing, interfaces, safety, variability and long-term maintainability are still decided by architecture, and every partition between components or teams moves complexity to an interface that someone must own.
This talk examines what changes for architects when AI generates much of the implementation: where design intent gets lost, why interface contracts and architectural decisions must be explicit and machine-readable, and how to keep human accountability in the loop. Drawing on a use case from our high-tech engineering practice, we show what happens when a team treats architecture as the control point for AI-assisted development, including what worked and what didn’t. Attendees leave with a practical checklist for making their architecture AI-ready, independent of any tool or vendor. We also discuss common pitfalls and the guardrails that prevent them.

Mobility is what you can see. Mission success depends on everything that enables it. Forterra’s work within CUGS integrates RNLA mission autonomy software with autonomous navigation, sensing, compute and communications, four pillars that together turn a platform into something interoperable, scalable and capable of extending reach into contested environments no soldier should have to enter. This talk asks why autonomous navigation is the fundamental enabling technology beneath that architecture and how Forterra and CUGS are building toward it together as one integrated system rather than four separate capabilities.

I’ve been asked this to my face, more than once, walking into a new R&D team: “Yet another product manager. What do we need you for?” Usually, it’s the systems architect asking. Fair question, and AI has made it sharper.
Here’s my answer. The architect and I do the same job from two sides. The architect is the technical conscience: What can we build, what holds together, what’s possible? The product manager is the business conscience: What’s worth building, what will the market pay for, what actually ships and sells? AI is brilliant at producing more: more concepts, more options, more half-finished work thrown over the fence. Deciding which of it is worth anything is the part AI can’t do. And that part only works when architect and product manager are aligned.
Expect a provocative, lively session, with stories straight from R&D-driven companies, including the ones where I had to win this argument on the floor.

Generative AI and large language models are transforming software development, from code generation and debugging to increasingly autonomous coding workflows. Tools such as Claude Code, Github Copilot and Gemini are changing how developers write, review and maintain code. While these tools promise increased productivity, their limitations introduce significant security challenges.
This talk explores both sides of AI code generation, examining its strengths and weaknesses, the risks of generating vulnerable code, dependency hallucinations and the security implications of agentic coding. It also addresses the less visible risks surrounding privacy, safety and the black-box nature of these tools. Through real-world case studies and practical demonstrations, attendees will see how GenAI can affect software security and learn how to use these tools more responsibly to support the development of secure software.

Refactoring a large software system can feel like trying to untangle a knot without knowing which thread to pull. Architects must identify hidden dependencies, remove unwanted coupling, extract reusable functionality and reorganize components – often without reliable design documentation. The work is valuable, but painstaking and difficult to perform manually.
This talk demonstrates how an AI agent can work directly with software architecture analysis tools to make that process faster and more systematic. Using dependency structure matrices and the Model Context Protocol, the agent can explore a codebase, detect architectural violations, identify tightly connected components and recommend practical refactoring steps. It can also evaluate architectural patterns – such as layered architecture – and suggest how existing modules could be rearranged to achieve them.
The approach is demonstrated on IsoAgLib, a 50,000-line embedded software codebase, where the agent discovered layer violations and produced concrete proposals for improvement. Early experiments achieved a 17.8 percent reduction in coupling, outperforming conventional rule-based techniques.
For software architects, this points towards a compelling future: AI that doesn’t merely generate code, but helps understand, simplify and reshape entire software systems.

Legacy software systems contain decades of behavioral knowledge, but much of it is hidden in tests, code and documents that were never designed to explain themselves. When we started the LLM4Legacy project with Philips, our goal seemed straightforward: Migrate legacy tests to behavior-oriented specifications without losing what made them valuable.
Our first approach was deliberately conservative. We relied on deterministic analysis to reconstruct behavior while preserving traceability and execution semantics. The results were reassuring but also revealed an unexpected problem: We preserved too many implementation details and couldn’t raise the abstraction level.
To move away from implementation-level descriptions, we introduced a knowledge graph connecting requirements, tests, code and recovered behavior. This shifted AI’s role from translating artifacts to interpreting them.
In this talk, we follow the project’s journey from deterministic reconstruction to AI-guided behavioral understanding, showing how knowledge graphs can help bridge the gap between legacy software and modern AI-assisted engineering. We’ll share the approach, early observations and the challenges that remain as the project continues to evolve.