IN Brief:
- QNX surveyed 1,100 embedded automotive developers, who reported spending an average 35% of their time on foundational software integration.
- Debugging and testing was cited by 44% of respondents, ahead of integration complexity at 39%.
- Three-quarters said the lack of a reusable software foundation slows software-defined vehicle development.
QNX has published research in which automotive software developers reported spending an average of 35% of their working time integrating foundational software rather than building new vehicle functions. The findings highlight the amount of engineering work required beneath the application layer of software-defined vehicles.
The second annual Under the Hood report draws on 1,100 embedded automotive developers surveyed across eight markets by OnePoll between 20 July and 4 August 2026. QNX commissioned the online research, so the figures represent respondents’ experiences and views rather than measured working hours across the automotive industry.
Nineteen per cent of respondents said at least half their time was occupied by integration. Another 75% agreed that the absence of a common, reusable software foundation slows software-defined vehicle development. Those answers describe perceived constraints, not a controlled test of one software architecture against another.
Modern vehicle functions operate across application software, operating systems, device drivers, middleware and electronic hardware. An application may require information from several sensors while also communicating with other controllers and meeting timing limits. Even when its core algorithm works, those connections have to be configured and verified.
Suppliers can develop individual components using different processors and software frameworks. Integrating them involves matching interfaces, data formats, diagnostics and expected operating behaviour. A change to a driver or operating system can expose faults in applications that have not themselves been modified.
Processor scheduling and shared resources introduce further constraints. Two software components can perform correctly when tested separately yet interfere with one another through memory contention, delayed communications or peripheral access once deployed on the same controller.
In zonal and centralised electronic architectures, functions formerly distributed across separate electronic control units may share more capable computing platforms. This can reduce hardware duplication, but it also creates a need to isolate workloads with different timing, security and functional safety requirements.
A reusable foundation can provide common operating-system services, hardware abstraction and communication interfaces. Reuse may reduce the amount of supporting code written separately for each vehicle programme, although software still has to be configured and validated against the selected processor, peripherals and safety goals.
The survey found 76% of developers believed manufacturers should place greater emphasis on application-level innovation than repeatedly developing supporting infrastructure. That was lower than the 80% recorded in the preceding annual survey, but the research does not establish why views changed.
Debugging and testing was the most frequently cited immediate development challenge, selected by 44% of respondents. Its share increased eight percentage points from the prior year and exceeded integration complexity at 39% and lengthy development cycles at 37%.
Diagnosing faults across multiple software layers can require engineers to correlate application logs, operating-system behaviour, communications traces and hardware events. A fault visible in the user-facing application may originate from timing or resource interactions several layers below.
Testing must therefore cover combinations of events as well as isolated functions. Automated tests and simulation can reproduce defined conditions, but they depend on the accuracy of the models and test cases used. Hardware-dependent behaviour still requires suitable measurements and system-level validation.
Recalls were also affecting engineering practices, according to respondents. Fifty-three per cent said events elsewhere in the industry had directly influenced their work, while 88% reported major or moderate changes to development practices following failures or recalls. The survey did not measure whether those changes subsequently reduced defects.
Cybersecurity was the leading future concern, selected by 48% of developers. Eighty-three per cent expected software-defined vehicles to become major cyberattack targets within three years. Those figures are reported expectations rather than forecasts derived from observed future incidents.
Connected functions and software updates require the protection of authentication credentials, communications and software integrity. Where manufacturers rely on components maintained by different suppliers, vulnerability handling and update responsibilities must remain clear over the vehicle’s service life.
Developers also described pressure to release features quickly: 79% said faster-moving competitors were affecting their work. At the same time, 46% identified better tool integration as a way to free engineering capacity, with 38% selecting greater software reuse and 34% choosing pre-integrated foundational software.
Expectations of artificial intelligence were more measured than in the earlier report. The share calling AI transformational fell from 36% to 25%, although 62% expected it to become a significant part of their workflows. Generated code and automated test cases still require verification, particularly in safety-related systems.
QNX supplies automotive operating systems and supporting technologies, giving the company a commercial interest in the subject of common software foundations. Its research offers a view of reported development pressures, but does not quantify improvements achieved through QNX products or demonstrate that any single development environment resolves them.
The findings identify integration, debugging and security as areas where surveyed teams are investing substantial effort. Individual vehicle programmes must determine whether a shared software foundation can meet their interface, timing and safety requirements before any practical reduction in engineering workload can be established.
