Ahsan's journey spans mechatronics, robotics, and autonomous systems. What ties his career together is a relentless curiosity about how complex systems behave, break, and can be built better. He points to three key challenges, and opportunities, in modern software development for platforms that power a wide range of applications:

1. Co-design of hardware and software across the entire stack
2. Rapid iteration from product design to test, powered by agentic AI and digital twins, and replay of field scenarios
3. System integration and test loops across distributed suppliers

Each of these is deeply technical, difficult to get right, and foundational to the challenges automotive and software-defined vehicle (SDV) teams face today.

1. Co-design of hardware and software: where functionality meets physical reality

In modern complex systems — drones, eVTOL aircraft, robots, and vehicles — features don't live in isolation. They sit atop multiple layers of software: middleware, firmware, operating systems and hypervisors, and ultimately device drivers, all married to a compute architecture that brings together microcontrollers and microprocessors. Many of these systems must also be safety-critical. That combination demands hardware-software co-design to manage the complexity.

Ahsan explains that one way to handle this complexity is through a design philosophy shaped by years of robotics research, which he calls “robot principles.”

“Some things must be a ‘local reflex’; others are ‘reasoned centrally.’ Complex systems can be designed with a similar ideology, and similar trade-offs.”

Electrical architectures are constantly evolving. For every new feature, the same questions arise: What must run close to the I/O, within a 10–20ms loop, as a local reflex? What functions aren't bound by physical I/O or hard real-time constraints, and can therefore be reasoned about on compute that sits farther from the sensing and actuating units? And how do you balance performance, system safety, security, and cost within that ideology?

Consider an adaptive glare-free beam as an example. Its functions split naturally into central and local roles:

• Central reasoning: High-level cognitive control that takes the perception system's output, determines where objects are located, and decides which LEDs need to be dimmed for those objects — producing a glare-free policy that outputs either a LightMask (a beam canvas) or a ChannelSet (predetermined LED channels).
• Local reflex: Low-level control that takes the high-level policy decision and determines which LEDs to turn on or off (light mask) or which channels to trigger (ChannelSet). It also implements safety functions, local coordination or obstacle detection, thermal management, safety timeouts, and LED emitter protection.

Getting this right requires hardware that supports both interference-free fast loops and enough bandwidth for high-level instructions. Every decision creates cascading trade-offs: keep logic local, and performance becomes real-time predictable, but hardware may be constrained. Centralize logic, and hardware becomes more capable - but network load, latency, and failure sensitivity all increase.

As Ahsan summarizes: as electrical architectures evolve, that evolution must go hand in hand with how functionality is realized on top of them.

2. Rapid iteration from product design to test, and replaying field issues

Digital twins are often marketed as a vision. For system architects and systems engineers, though, the value is very concrete: how quickly can a product idea be running in an environment that faithfully represents the algorithm, software stack, hardware, network, and physical-domain constraints it will face? And how quickly can a field issue be reproduced and understood?

Behavior models often already exist. Hardware models of compute, and models representing physical constraints, typically don't. Virtualization solutions are fragmented and don't transfer smoothly across levels. Recreating environmental conditions — heat, network jitter, physical mechanics — requires multi-layer modeling.

Ahsan points to a common example: a locking performance issue observed in the field. Reproducing it requires:

• Behavior models of the latch control system and the controller logic that determines when to lock, unlock, or release
• Hardware models of the latch compute module and the microchip running that logic
• Physics-based models of doors, seals, and latches that represent the physical constraints in a plant model

Most organizations have only the first.

Agentic AI is changing how design and digital twins work together. A design-pipeline agent can generate design candidates from product requirements and domain constraints. Those candidates feed into a deployment pipeline running a digital twin, which tests them against hardware, network, and physical constraints, learns from failures, and feeds that learning back to regenerate an improved design. The twin acts as a simulator, a specification of the physical domain the system under test must ultimately perform in. This setup lets agents rapidly explore a design space, learn and apply constraints to prune candidates that don't meet them, and carry forward the ones that do for further exploration. The result is a tight loop of constraint-based exploration and simulator-based validation that lets teams learn from failures, correct them, and converge quickly on a candidate that satisfies a product requirement under real physical-domain constraints.

To move forward, Ahsan sees three necessary shifts:

• A platform solution across the ecosystem. No single company can do this alone. Building blocks integrated into a standard, reusable mechanism are key enablers for software-defined products.
• Closer collaboration between application teams and virtualization enablers such as RemotiveLabs and Synopsys.
• Making virtualization mainstream, not a prototype side-project. Verification and validation plans need a test framework that supports early execution on models, containers, hardware emulation, or HIL. Allowing content fidelity and hardware fidelity to increase gradually and in step. RemotiveLabs' virtual harness is built to support exactly this kind of testing framework. Ahsan's refences a recent RemotiveLabs use case on Arm Developer blog: Digital twins for automotive development.

“RemotiveLabs helps bridge Level 1–2 virtualization with system requirements. You can start with behavioral models and gradually add topology, middleware, and hardware layers. The more you add, the more issues you can find and replicate early.”

3. System integration and test loops across distributed suppliers

Vehicles are a web of interconnected components, many built by different suppliers. System integration is where everything comes together: software, hardware, interfaces, timing, behavior. For Ahsan, success here depends on two things:

• A clear integration contract that every participating element must meet before it enters an integration test.
• A fast loop from logging an issue, to triage, to fix, to re-running the test.

The main challenge, Ahsan notes, isn't finding issues during integration — it's how fast you can fix them.

Suppliers sometimes interpret requirements differently, and interfaces evolve late. Pipelines are disconnected across organizations. Integration is expensive and slow, and hardware availability limits how quickly teams can iterate. Ahsan outlines a path forward:

• Define integration contracts linked to behavior and topology
• Use virtualization to validate supplier software before it enters an integration test
• Feed issues back into supplier pipelines quickly
• Run system tests continuously, long before hardware delivery

“If suppliers can run the same tests virtually and get fast feedback loops, everyone wins.” concludes Ahsan Qamar.