What’s one thing happening in the industry right now that people can’t afford to ignore?
One important development that the industry cannot afford to ignore is the growing regulatory and consumer-safety focus on how drivers interact with the cockpit. Euro NCAP’s 2026 protocol places greater emphasis on providing easily accessible controls for important functions such as indicators, hazard lights, the horn, windshield wipers and headlights. China is moving even further, with proposed requirements covering functions such as ADAS activation, defrosting and power-window operation.

However, I believe the bigger signal is not simply the return of physical controls. The bigger signal is that the HMI is becoming a safety-relevant engineering artifact that must be objectively validated. The layout, information hierarchy, control placement, visibility and interaction behavior can no longer be treated only as matters of design preference. They must be evaluated against measurable safety and usability requirements. The challenge is that many organizations still do not have the tools needed to measure these characteristics continuously and at scale.

What’s the biggest misconception in your field?
The biggest misconception is that automotive HMI testing is essentially mobile-app testing on larger screens. An automotive cockpit operates under very different conditions. A mobile application typically runs on one device and one operating system. An automotive HMI may operate across a center display, instrument cluster, head-up display, passenger display and rear-seat displays. These surfaces can have different sizes, configurations and responsibilities, and they may run on different operating systems. They must also respond correctly to vehicle signals, driving states, regional restrictions and multiple forms of input, including touch, voice, steering-wheel controls and physical switches. Traditional manual quality assurance and mobile-style automation alone cannot scale to the complexity and release frequency of modern software-defined vehicles. Automotive HMI validation must examine not only whether a function works, but also whether the correct information appears on the correct display, in the correct state, at the correct time.

Many OEMs are accelerating their software-defined vehicle strategies. Where do you see the biggest validation gaps emerging today?
I see four major validation gaps. The first is the design-validation gap. Designers may create an approved design, but teams still need to determine whether that design works across all vehicle variants and whether it satisfies applicable automotive safety and usability requirements.

The second is the cross-display and cross-OS verification gap. Individual applications may work correctly, but teams must also verify that data and visual states remain synchronized across the center display, cluster, head-up display and other surfaces.

The third is the OTA regression gap. A relatively small software update can affect components and screen states far beyond the area being modified. Without effective impact analysis and automated regression testing, it is difficult to know how much of the cockpit must be revalidated.

The fourth is the contextual-safety gap. A platform may expose the current vehicle state or applicable UX restrictions, but that does not automatically prove that the rendered interface follows those restrictions. We must verify the actual behavior and the pixels presented to the driver. Closing these gaps requires a combination of virtualized testing, signal-aware automation, visual validation and targeted physical testing. No single tool can solve the entire problem.

AI is increasingly being applied across vehicle development and validation. What opportunities does it create, and what limitations should engineers be aware of?
AI creates several opportunities across automotive HMI development and validation. First, a generative system can use a verified automotive UI database together with contextual inputs to propose an interface appropriate for a particular situation. For example, it could simplify the screen during a demanding driving situation and prioritize navigation, warnings or frequently used controls. The proposed layout can then be checked by a separate deterministic safety gate. The AI generates the design, but the deterministic gate decides whether the design satisfies the mandatory rules.

Second, vision-language models can inspect an interface in a way that is closer to human visual review. They can compare a rendered screen with an approved design and reason about text, alignment, element states, visual hierarchy and behavior under different contextual inputs.

Third, AI can help generate and prioritize test cases using UX specifications, system requirements, vehicle context and recent software changes. It can also help provide dynamic inputs to the system under test and identify combinations that may otherwise be overlooked.

At the same time, engineers must recognize that AI models are probabilistic. They can report defects that do not exist, miss subtle icon or color-state changes, and sometimes produce different conclusions for the same inputs. For that reason, safety critical requirements such as mandatory control presence, vehicle-state restrictions, minimum target sizes and alert priorities should be enforced through deterministic and auditable code. Low-confidence AI conclusions should be routed to a human reviewer rather than automatically treated as a pass or failure.

What should engineers working on software-defined cockpits be focusing on over the next few years?
Building cockpit architecture that’s observable, testable and fails safely. Make your design specification machine readable. If your spec carries roles for UI elements, target sizes, priorities and the contextual conditions each applies to, it stops being a picture and becomes ground truth a machine can check against. That one change unlocks most of the automation downstream.

Turn the distraction rules into executable constraints. ISO 15008 and the NHTSA guidelines currently live in documents that designers cite. They should be code running in your validation pipeline, returning pass or fail. Rules you can execute, not rules you can quote.

Move validation into software-in-the-loop and virtual environments, so you can exercise large configuration matrices before hardware exists. HIL still matters but it should be spending its time on timing, integration and physical behavior, not repeating basic UI checks that could have run in simulation.

And use AI aggressively wherever the output is checkable, but treat everything it produces as unverified until it’s been through the same static analysis, review and traceability you’d apply to human work. The goal isn’t maximum autonomy. It’s maximum useful automation with a clearly defined failure mode, and a human in the loop where the model is unsure.

You will be speaking on this subject at the Automotive Design & In-Cabin Conference at Vehicle Tech Week North America in October. What will attendees learn from your presentation that they won’t get anywhere else?
This session connects two parts of the problem that are usually discussed separately. The first is preventing an unsafe or distracting interface from being designed in the first place. This is addressed through context-aware generation combined with a deterministic safety gate. The second is proving that an approved design was implemented correctly in the actual vehicle software. This is addressed through vision-language-based design-to-build validation.

These are two different failure modes. A design itself can be unsafe, or a safe design can be implemented incorrectly. Solving only one of these problems still leaves the cockpit exposed. Attendees will see how the two approaches can form a closed validation loop – from context and design intent, through implementation, to the final pixels rendered inside the vehicle. They will also leave with a practical understanding of where AI adds value, where deterministic validation is required and where human judgment must remain part of the process.

What are you hoping to learn, explore or discover at Automotive Design & In-Cabin Expo North America?
I want to understand how other organizations are validating the complete cabin experience rather than individual components. Specifically, how teams are handling cross-display synchronization, driver monitoring, adaptive interfaces, accessibility, display performance, and the integration of physical and digital controls. And I’m looking for practical examples of AI that have actually crossed from demonstration into production engineering workflows not pilots – production. Most of all, I want to find out where OEMs, suppliers, designers and test-tool providers draw the boundary between virtual validation and physical cabin testing.

Don’t miss Kumar’s presentation, titled ‘Bridging the SDV validation gap: An AI-driven framework for verification and validation in the multiple display and multi-OS cockpits,’ at Vehicle Tech Week North America, October 27-29, 2026. Read more about this presentation in the September 2026 issue of ATTI, and find full details on Automotive Testing Expo North America 2026 here

The new site in Ilava has created 100 jobs and will increase production of the Terrastorm and Praetorian ranges. It also strengthens the ability of Torsus to develop and manufacture specialist vehicles for mining, energy, emergency response, construction, government and remote industrial operations.

Torsus founder and CEO Vakhtang Dzhukashvili stated, “Slovakia gives Torsus access to exceptional automotive engineering expertise, a strong supplier network and an ideal location from which to serve customers around the world.”

Together with the company’s existing pre-assembly operation in Horné Srnie, Ilava gives Torsus a combined manufacturing footprint of 9,420m² and a Slovak production team of more than 150 people.

The Ilava facility brings together digital engineering, prototyping, specialist metal fabrication, vehicle assembly, quality control and parts fulfillment. The expanded operation provides annual production capacity for up to 200 Terrastorm and 50 Praetorian vehicles, with multiple models and customer projects able to progress through production simultaneously.

Dzhukashvili explained, “The new Ilava facility gives our teams more space, greater production capacity and the tools to move faster from digital design to prototype and finished vehicle.”

From digital design to working vehicle

At the center of the facility is the Torsus Digital R&D Centre, where engineers develop vehicle systems, specialist conversions and customer-specific equipment.

Advanced CAD software, including SolidWorks and Plasticity, allows the team to create detailed three-dimensional models of components, assemblies and complete vehicle systems before production begins.

According to Torsus, in-house 3D printing accelerates the development of customized parts, enclosures, interfaces and mounting systems. Engineers can reportedly move quickly from a digital concept to a physical prototype, assess it on the vehicle and make changes without waiting for conventional external tooling.

A dedicated prototyping area, separate vehicle lift and specialist engineering workstations allow development work to continue alongside regular vehicle production.

4×4 HD built for tough conditions

A major focus of Torsus’s engineering operation is its heavy-duty 4×4 HD system for specialist commercial vehicles with a gross vehicle weight of up to 5.5 metric tons.

The system combines low-range gearing with locking differentials, reportedly giving operators greater traction, torque control and low-speed maneuverability across steep gradients, mud, loose surfaces, cross-axle obstacles and broken terrain.

The drivetrain is engineered alongside reinforced suspension, underbody protection, drivetrain breathers, electronics and customer equipment. Vehicle weight, axle loading, center of gravity and suspension behavior are assessed to ensure the completed vehicle remains stable and controllable under full-load off-road conditions.

Dzhukashvili added, “Our customers operate in environments where traction, durability and reliability are essential. Expanding our engineering and manufacturing capabilities means we can deliver more Terrastorm and Praetorian vehicles, support increasingly specialized applications and maintain the quality expected from every Torsus.”

In related news, rigorous RAM-D program at military facility validates Torsus Terrastorm 4×4 HD

For autonomous platforms built without a steering wheel or traditional foot controls, the mandate for a physical cabin interface disappears. Crucially, however, the physical stopping distances that vehicle dynamics and computer-aided engineering (CAE) teams validate against remain entirely unaltered. For testing departments, the challenge is structural: while the physical targets haven’t moved, the actuation command, data instrumentation and type-approval certification package must be completely reengineered.

Bridging the legacy gap

First issued in 1995, FMVSS No. 135 defines stopping distance as the exact interval between the moment force is applied to the physical brake control, to the point at which the vehicle comes to a complete stop. The historic framework relies on that force originating from a foot-operated control. Although this works seamlessly for driver-operated setups, it introduces severe engineering anomalies for ADS platforms where braking commands manifest as electronic controller area network (CAN) packets routed to a linear actuator.

Furthermore, NHTSA acknowledges that for fully autonomous robotaxis, a physical pedal assembly represents an active cabin safety hazard. An occupant accidentally or intentionally depressing a legacy pedal during automated operations could induce severe systemic conflicts, overriding or corrupting the safety logic of the automated driving system.

Evolving definitions of actuation

The new NPRM restricts traditional foot-pedal and manual parking brake rules strictly to vehicles maintaining physical controls. For purpose-built ADS vehicles, the service and parking brakes must be triggered exclusively by onboard computing architectures, with external remote command signals strictly precluded.

To bridge the engineering gap, the proposal introduces a broader definition of a ‘service brake control.’ For pedal-less designs, this includes any physical or solid-state component that translates an incoming electronic command into mechanical input for the hydraulic or brake-by-wire system. Track testing and laboratory procedures will be modified accordingly: standard pedal-force requirements will be set aside in favor of manufacturer-provided specifications defining baseline control inputs. Additionally, the traditional dashboard warning telltale must be engineered to be clearly visible from any designated seating position inside the cabin.

The physical limits of braking performance remain untouched. A pedal-less robotaxi must continue to demonstrate a cold-effective stopping distance of 70m or less from an initial velocity of 100km/h. Thermal fade requirements remain equally rigid, demanding that at least one of two consecutive hot stops from 100km/h registers at 89m or less. Wheel lockup constraints remain capped at 0.1 seconds above speeds of 15km/h, and manual anti-lock braking system (ABS) override controls remain strictly banned.

The data instrumentation challenge

While the physical performance dimensions of the NPRM are unambiguous, establishing compliant verification procedures introduces serious friction for track-test engineers. Legacy testing protocols rely heavily on a calibrated load cell mounted directly to a physical pedal to measure normalized occupant force. In an ADS vehicle, that physical force is replaced by a decentralized network command, be it a target deceleration rate, a specific torque request sent directly to a brake-by-wire module, or a positional target for a master-cylinder actuator.

Currently, there is no standardized industry consensus identifying which digital bus signal represents the definitive equivalent of a human ‘panic stop’ application. In response, NHTSA has opted to defer to individual OEM specifications. While this approach maintains strict technology neutrality, it shifts a substantial engineering burden onto the regulatory certification package. Homologation teams must clearly define a ‘maximum input’ condition that aggressively stresses the hydraulic lines, document all underlying signal architectures, and satisfy compliance auditors that the chosen software state genuinely simulates a worst-case emergency stop. Consequently, third-party compliance testing facilities will require comprehensive access to proprietary signal dictionaries to inject these explicit commands directly onto the vehicle network bus alongside existing deceleration and wheel-speed data acquisition (DAQ) channels.

The thermodynamic compensation conundrum

This operational paradigm shifts the focus toward brake fade and thermal recovery tests. Traditional testing stresses thermal margins through predictable, repeated manual pedal applications. Conversely, an autonomous vehicle governed by an integrated deceleration controller will dynamically adapt to fading friction coefficients by automatically ramping up its internal line pressure or torque requests to hit its deceleration targets.

This behavior forces a technical impasse that the industry must resolve: should the controller’s active thermal compensation logic be considered a native component of the system under evaluation, or must that closed-loop logic be inhibited during compliance validation to isolate and characterize the raw, underlying hardware? The current NPRM leaves this operational parameter unresolved, creating a vital target for industry feedback.

Strategic action before the deadline

The proposal explicitly sidesteps how passengers might interact with an emergency-stop sequence or how the ADS core should arbitrate such inputs. For the immediate future, any unforeseen passenger-interaction risks will fall under NHTSA’s broad defect enforcement authority, while a comprehensive, dedicated ADS performance standard is drafted for long-term implementation. Ultimately, the revised FMVSS No. 135 framework validates whether an autonomous vehicle is mechanically capable of stopping within a safe physical boundary once a command propagates; it does not evaluate whether the perception stack or path-planning software calculated that command at the appropriate timestamp.

Formal industry comments under docket NHTSA-2026-0728 must be submitted by July 27, 2026. This proposal marks the fifth standard modernized under the AV Framework, yet it represents the absolute first iteration where hardware removal alters real-world physical performance measurements rather than secondary cabin convenience features. For engineering units inside OEMs, Tier 1 system suppliers and testing laboratories, focus must remain on providing highly granular feedback regarding signal documentation baselines, closed-loop compensation parameters during thermal degradation, and standardizing passenger-system interactions. The physical removal of the pedal makes for an easy headline, but the underlying narrative is a complex, line-by-line adaptation of a 1995 protocol to an entirely digital machine.

Sources

• NHTSA Notice of Proposed Rulemaking, “Federal Motor Vehicle Safety Standards; Modernization of FMVSS No. 135 To Accommodate ADS-Equipped Vehicles,” Federal Register, 26 June 2026 (Docket NHTSA-2026-0728).
• NHTSA press release, “Trump’s Transportation Department Launches Commonsense Updates to Brake Pedal Requirements for AVs,” 25 June 2026.
• 49 CFR § 571.135, “Standard No. 135; Light vehicle brake systems.”
• Sidley Environmental, Health, and Safety Brief, “NHTSA Proposes Amending Federal Brake Standards for Autonomous Vehicles,” 29 June 2026.

More on safety standards and passive safety testing in this year’s edition of Crash Test Technology International, the sister title to ATTI. Read both magazines online

The original hybrid battery cells used in the P1 were manufactured in 2010. After 16 years of service, numerous units have deteriorated to the point that they must be replaced, otherwise the car will be undriveable.

Project Continuum from V Engineering offers current and future McLaren P1 owners an alternative high-voltage battery solution that improves energy storage and reduces the overall weight of the original battery with no penalty to the existing power delivery. Another key user feature of the new battery is that it offers extended EV range compared with the factory production unit.

Developed in collaboration with engineers involved in the original P1 program, the battery features a glycol-based cooling system with significantly improved heat rejection properties from the newly developed cells. The battery solution is built around a proven, high-performance 21700 lithium battery module engineered to FIA Formula E requirements to offer motorsport-grade technology. The plug-and-play approach from V Engineering reportedly improves performance and reliability while retaining compatibility with the vehicle’s existing electrical architecture.

Along with the advanced cooling properties of the new battery, design also focused on the energy storage capacity of the new unit, which has been increased to 12.4kWh compared with the standard 4.72kWh of the original P1.

Customer installations are scheduled to begin in spring 2027, with V Engineering currently in discussions with owners from the UK and Europe, the Middle East and the USA.

Project Continuum is the first phase of a broader powertrain development program intended to provide long-term technical support for McLaren P1 owners.

In related news, Agentic AI transforms McLaren Automotive’s entire engineering process

“The Nuvolari project is a striking example of how quickly we at Audi can bring an idea to life – that is ‘vorsprung durch technik,’” said Audi CEO Gernot Döllner. As the OEM states, the new model is much more than a supercar – it guides the way for future Audi developments and provides important impetus for the brand’s technology portfolio.

“The Audi Nuvolari is the fastest and most powerful road car we’ve ever produced,” noted Rouven Mohr, member of the board of management for technical development.

At the same time, the project represents a new kind of collaboration at Audi: from the very beginning, experts in design, vehicle technology, aerodynamics and powertrain worked closely together in an autonomous, focused project team. Short lines of communication, quick decisions and the close integration of all disciplines enabled the development project to move forward at a rapid pace.

“The Audi Nuvolari shows that, when you have the right mindset and close teamwork, you can succeed in delivering rapidly without making any compromises,” added chief creative officer Massimo Frascella.

A development journey across Europe

From the initial designs in Ingolstadt to cold-weather testing with technology demonstrators in Lapland, lightweight construction in Neckarsulm, tests in the Ingolstadt wind tunnel, suspension tuning in southern Spain and high-speed tests in Nardò, Italy, Audi’s engineers worked hand in hand to develop the Nuvolari in record time.

“When the Nuvolari took to the road for the first time, the best part was seeing the expressions on the faces of the people who had developed it,” recalled Döllner. “Seeing something that had existed only as a sketch come to life for the first time was indescribable.”

Final touches with Formula 1 expertise

Four hundred and five days after the initial idea, the project team presented the first driveable prototype. The Audi Revolut F1 drivers then took over testing duties. Gabriel Bortoleto drove the Nuvolari on the high-speed track at the Nardò Technical Center. Before the drive, he stated, “I’m definitely going to push it,” and waxed lyrical about its performance afterward.

At the test track in Neustadt an der Donau, F1 teammate Nico Hülkenberg also pushed the Nuvolari to its limits. “The acceleration and the full system output of more than 1,000ps – that’s a real statement.”

In June 2026, the Audi Nuvolari debuted.

In related news, Audi A2 e-tron racks up the miles during validation testing

Kwon is an autonomous driving AI expert who has worked at leading global tech companies. He oversaw autonomous driving software development and commercialization at Nvidia. Most recently, Kwon led intelligent robot development at Samsung Electronics.

Drawing on his deep expertise in autonomous vehicle perception software, deep learning, machine learning and computer vision technologies, Kwon will lead the group’s autonomous driving technology development from conception through product commercialization.

Strengthening global talent pipeline

The OEM is recruiting key talent in software-defined vehicles and autonomous driving to accelerate the realization of its physical AI vision.

Early in July, the group appointed Dongwuk Kim as a senior vice president and head of the SDV Platform Development Center. Kim previously led wireless communication systems development for mobile devices, vehicles and humanoid robotics at global companies including Apple and Tesla.

And Jeremy Ma joined as a senior vice president and head of the AVP Silicon Valley, bringing extensive experience in robotics as well as autonomous driving software development and commercialization from Apple, Toyota Research Institute and Nvidia.

The September issue of ATTI will feature an interview and an opinion piece with Dong Chul Park, former research fellow and head of sound design at Hyundai

Vehicles today are continuously evolving software platforms, which puts new pressure on how testing is structured across the lifecycle. To keep up with frequent releases and OTA updates, the optimal use of SIL, HIL and vehicle integration (VI), also called vehicle-in-the-loop, becomes a strategic element rather than a tooling detail.

In SDVs, functions are updated long after SOP, so relying on late-stage vehicle tests alone is no longer viable for safety or schedule. There is considerable pressure to maintain a rapid, continuous release cadence. Testing must be pushed earlier into development while still providing defensible evidence for safety cases and regulatory expectations over multiple software generations.

A layered approach – SIL, HIL and VI combined with on-road testing – provides a progression from fast, scalable virtual (model) checks to highly realistic, driver-in-the-loop evaluations. When those layers are integrated into a coherent architecture, they enable continuous regression across every release and OTA campaign. From my experience, I place great value on regression testing.

If you have read any of my work, you will know my penchant for a common lexicon. SIL enables feature exploration before production on a virtual ECU (subsystem) or host, connected to simulated components, sensors and communication networks (models). It is optimized for early virtual system integration testing, enabling rapid execution of thousands of scenarios before hardware and full production software are available.

HIL adds realism by connecting real ECUs or domain controllers to real-time components and network models on a test bench – a vehicle in the lab. This enables verification of timing behavior, network load, diagnostics and safety mechanisms under controlled yet representative conditions, well before full vehicles are built. From experience, securing time on the vehicle is not trivial, and we need to have some confidence in the product and system before VI.

VI testing takes place in a real vehicle on a proving ground, with its perception and control systems interacting with a controlled virtual environment. VI bridges the gap between lab rigs and road tests, enabling safe, repeatable execution of complex, hazardous scenarios that would be difficult to stage in the real world, in real time.

SIL, HIL and VI deliver the most value when they are treated as a progression rather than as competing options. SIL is ideal for early, rapid fault discovery, software refactoring and large-scale scenario sweeps during early development, when interfaces are still fluid and hardware is not yet fixed.

Once software stabilizes and hardware is available, HIL becomes the workhorse for ECU and domain-level integration, confirming that real electronics and networks behave as expected under realistic loads, failures and transients. VI and structured on-road campaigns then take over for full system behavior, human-machine interaction and vehicle dynamics in complex traffic, while reusing core scenarios defined earlier in SIL and HIL.

In an optimized SDV strategy, scenarios and requirements are progressively elaborated through learning enabled by SIL, HIL and VI. A lane change with a cut-in vehicle, for example, is first debugged in SIL, then checked for timing and network behavior in HIL, and finally executed in VIL on a controlled track and then on-road tests to confirm full-system performance.

Because SIL and HIL rely on virtual elements, sensors and environments, the credibility of their results depends on model veracity. Model veracity includes fidelity (the extent to which the model details represent the actual system), validity range (the range of applicability) and quantified error relative to physical measurements.

A practical approach is to treat model correlation as a formal activity. Engineering, rig, dyno and track tests are used to calibrate models; error bounds are computed for key outputs, such as forces, temperatures, signal delays and sensor artifacts; and these bounds are documented as part of the test environment definition. This makes it clear which requirements can be verified with confidence in SIL or HIL, and which still require VI or real-world testing due to model limitations.

When SIL, HIL and VI are used as a coherent stack, with clear definitions, effort to obtain strong model veracity and disciplined configuration management, they become an enabler for continuous delivery in SDVs. High-risk, safety-critical scenarios can be re-executed selectively in SIL and HIL for each code change. At the same time, VI and on-road checks provide final confirmation before wide OTA deployment. The result is a test strategy that aligns with the SDV business model: rapid, frequent software evolution, anchored in a reusable body
of trustworthy test evidence spanning virtual benches, real hardware and real vehicles.

Kistler reveals why conventional in-cylinder pressure calculation models may not hold up when analyzing zero-carbon fueled engines 

Optimizing engines to efficiently burn zero-carbon fuels is a key task in the current shift toward a more sustainable future. A fundamental measurement requirement in the development of combustion system engines has long been the detailed analysis of combustion pressure data. However, for many, the basis for interpreting the test data still relies on calculation models for carbon-based fuel combustion. Given the chance to conduct their own extensive study at the University of Nottingham, pressure measurement experts from Kistler took a closer look at how these models hold up with these low or zero-carbon fuels. After tests with various ammonia-hydrogen mixtures, the experts were surprised by how significantly even small changes in the fuel-mix affected the derived results. The good news is that these findings might now help engineers optimize their combustion systems more efficiently.

Combustion pressure measurement gives engineers a clear image of what happens inside the engine during operation. To get relevant data, a small piezoelectric sensor is mounted directly in the cylinder head. As air and fuel are compressed and ignited, the rapidly increasing in-cylinder pressure is captured with high fidelity creating a detailed pressure curve for each combustion cycle. Based on this data, engineers know how fast the fuel burns, when exactly peak pressure is reached, how efficiently the energy is released and whether the combustion is stable. These insights are crucial for optimizing any combustion engine. They help with finding optimized combustion phasing to avoid knock or mechanical overload, improving fuel efficiency and reducing emissions.

In other words, measuring and analyzing combustion pressure is an indispensable tool for building better and more eco-friendly engines. Yet, researchers and engineers still rely heavily on simplified first-law heat release models, which typically assume fixed polytropic indices. Polytropic indices are thermodynamic parameters which lie at the core of the analysis. They describe how pressure and volume change during gas compression or expansion in the cylinder, providing insights into how much energy is retained or lost during the process.

Questioning the calculation model

The polytropic index commonly used in combustion analysis has been well established and proven in many years of research on engines burning hydrocarbon fuels. Other types of fuels, however, differ significantly in thermodynamic properties, flame speed, ignition characteristics and specific heat ratio. Experts at Kistler, a leading manufacturer of piezoelectric pressure sensors, wanted to explore the sensitivity of this aspect, with respect to zero-carbon fuels – and how much this might influence the results in engine development work. “We wondered whether parameters proven in the research of carbon fuels would hold up when applied to zero-carbon fuel combustion. So, we decided to look into it,” explains Dr David Rogers, head of ICE systems at Kistler, who led the study.

In collaboration with the Powertrain Research Centre at the University of Nottingham, the team decided to make the most of the opportunity to work with the sophisticated test equipment and research engine that the facility has.

The mixture of ammonia (NH₃) and hydrogen is increasingly considered a carbon-free fuel alternative with a high potential for heavy-duty combustion engines as used in marine propulsion applications. Ammonia and hydrogen have combustion characteristics that differ significantly from conventional carbon fuels: while ammonia has a lower burning velocity than gasoline, hydrogen has a higher one and their specific heat ratios are different as well.

The Kistler team wanted to explore whether gasoline-based assumptions are still valid for ammonia-hydrogen blends, or whether they might introduce systematic errors in burn-rate analysis, combustion phasing prediction and ignition delay estimation.

“Ammonia and hydrogen are tricky to store. Also, you need an engine that is able to burn it. Thanks to the university, we had access to both,” reveals Rogers. “We really did not know what to expect and would have been happy if nothing had shown up in our findings. But that was not the case.”

The test approach: Getting to the basis of combustion pressure analysis

The laboratory at the university was equipped with a modern single-cylinder spark-ignition research engine with variable valve timing, direct fuel injection and a dedicated port fuel injection for ammonia and hydrogen. The high-speed in-cylinder pressure data was recorded using a Kistler piezoelectric transducer (Type 6045B), which was flush-mounted in the cylinder head. The connected KiBox2 combustion analysis system from Kistler prepared the data for interpretation. The tests covered both pure ammonia combustion and various ammonia-hydrogen blends (up to 60% hydrogen share).

The measured in-cylinder pressure was used as the main input, converting the pressure curve into an energy release curve, showing how quickly and at what crank angle the fuel’s energy is released during combustion. The research team compared the standard polytropic index based on gasoline combustion with a more detailed method: based on the measured pressure data and the specific fuel blend, the polytropic index was calculated individually for each operating point and each cycle. This enabled the Kistler team to quantify the potential error that is introduced when standard gasoline models are applied to ammonia-hydrogen combustion. Conversely, they were able to quantify the increase in accuracy achieved through fuel-specific, cycle-resolved calculations.

The results: Faced with a large potential for errors

Rogers and his team were stunned by the results. “We found the sheer magnitude of the potential errors surprising,” he says. “For some of the operational points the errors were so significant that they rendered the test results borderline unusable.”

Under pure ammonia operation, the polytropic index deviated in compression by about 4% from the gasoline default value. The experts found out that the discrepancies primarily affected the late combustion phase, while the early burn phase was less sensitive. Also, combustion accelerated and modeling discrepancies decreased as the hydrogen share increased.

“Our findings show that conventional gasoline-based heat release analysis is not universally transferable to zero-carbon fuels,” summarizes Rogers. “For accurate prediction of burn duration and combustion phasing, fuel-specific or cycle-resolved polytropic indices are required.”

How these results help engineers create more sustainable engines

In day-to-day engine research and development, engineers are under a lot of pressure to quickly improve engines. Here, discrepancies in the test results require repeated measurements, making the whole process less efficient. With more accurate calculation models and, consequently, a more accurate analysis, engineering decisions can be made earlier in the development cycle.

“These combustion metrics are commonly used by our customers in their research and development, so of course we are interested in supporting them as best as we can,” Rogers explains of the motivation for their study. “Experimental work like this helps us a lot in doing so. We want the users of our technology to be confident about the quality of their analysis. The ultimate goal is to make the calculation models better and easier to use through our products. Ideally, the data is so precise and the analysis so conclusive that engineers will be able to make informed engine design decisions already during the measurement phase. This way, we can speed up development time significantly and help engineers create better and more efficient engines.”

In the next step, Kistler intends to embed these findings into its measurement technology to ensure seamless user access. The KiBox2 analysis system enables straightforward implementation of cycle-resolved polytropic indices.

Also, the team wants to do more experimental work – with different engine types and zero-carbon fuel mixtures. “This is just a small part of a bigger picture. The goal of our work is also to clear the path for more cooperations with partners from the industry and universities to continue our research,” concludes Rogers.

Requirements, specifications, simulations, implementations and tests in modern automotive development are often managed in different tools and environments. MCP reduces the need for manual handoffs by enabling AI agents to interact with dSPACE tools through standardized interfaces while keeping engineers in full control of reviewing and approving all activities and results.

dSPACE’s MCP-enabled tools enable AI agents to support engineering workflows spanning requirements analysis, software development, simulation preparation and validation across VEOS, ConfigurationDesk, SystemDesk, Bus Manager, ControlDesk and real-time hardware. The platform also feeds validation results back into the development process to support iterative engineering.

“AI delivers the greatest value when it can actively support engineering workflows rather than operate outside them,” said Jann-Eve Stavesand, director product portfolio management at dSPACE. “With MCP-enabled dSPACE tools, engineers can connect requirements, specifications, implementation and validation activities through AI-supported workflows while maintaining full transparency, traceability and engineering control. This allows engineering teams to streamline their validation workflows and transition more efficiently from requirements to verified implementations.”

By connecting AI Agents with simulation, configuration, measurement and validation tools, MCP-enabled workflows help reduce manual setup effort and streamline engineering processes. Engineers can transition more quickly from requirements and specifications to software validation on real hardware, while maintaining full traceability throughout the process. Validation results can be fed back directly into development workflows, enabling continuous refinement and accelerating the path from concept to validated implementation.

Recent news, Göpel Electronic launches modular battery cell tester

Simple Energy has expanded its use of the Siemens Xcelerator portfolio with Teamcenter X for product lifecycle management and Designcenter X for vehicle engineering. The company is also using Teamcenter X’s product configurator to manage vehicle variants and bills of materials, supporting collaboration across engineering teams while improving development efficiency.

“As our products scale in complexity, we’re strengthening the systems behind how we build them,” said Kiran Poojary, chief technology officer at Simple Energy. “With Teamcenter X and Designcenter X, we’re able to manage complex variants and large assemblies with greater speed and control – enabling us to accelerate development without compromising agility.”

“Simple Energy’s expansion of its Siemens’ software footprint demonstrates how customers can scale their digital foundation as product complexity increases,” said Mathew Thomas, vice president and managing director for India, Siemens Digital Industries Software. “Through close collaboration, we are supporting Simple Energy with a fully integrated vehicle engineering and lifecycle management digital thread that helps accelerate innovation and support its growth targets.”

Simple Energy initially adopted Teamcenter X to centralize product data management and improve engineering collaboration. As its electric vehicle programs expanded, the company extended its use of the software to manage enterprise bills of materials (BOMs) and vehicle variants using a configurable 150% BOM approach, enabling specific production BOMs to be generated for individual vehicle configurations.

To support increasingly complex vehicle development, Simple Energy has also replaced its legacy 3D CAD software with Siemens’ Designcenter X, integrated with Teamcenter X. The platform supports advanced surface modeling, large assemblies and 3D electrical routing, while Siemens says its value-based licensing model enables the software to scale with the company’s growth.

Related news, Göpel Electronic launches modular battery cell tester