In short
- A software-defined-everything revolution is currently changing hardware technology architectures.
- Automotive OEMs are leading this revolution with 80%+ of carmakers actively building software-defined vehicle architectures.
- Manufacturers and industrial automation companies are further behind in adopting software-defined architectures and can take 7 lessons from the automotive SDV playbook.
In this article
- Hardware is getting software-defined, and automakers are leading the charge
- 7 lessons manufacturers can learn from SDVs
- Lesson 1: Consolidate computing across the stack
- Lesson 2: The edge platform layer becomes very important
- Lesson 3: Decouple the software lifecycle from the hardware lifecycle
- Lesson 4: DevOps and toolchains bring “software-defined” to life
- Lesson 5: OTA is a game-changer
- Lesson 6: End-to-end security and compliance become its own discipline
- Lesson 7: AI impact is only seen once the software-defined foundation exists
- Analyst takeaway: What automation decision-makers should borrow, adapt, and avoid
- 3 software trends observed at SPS 2025 (Insights+ exclusive)
- Comparison of tech-native and traditional OEMS regarding SDV adoption (Insights+ exclusive)
Hardware is getting software-defined, and automakers are leading the charge
Entering the software-defined everything (SDE) era. Hardware is undergoing an architectural revolution toward software-defined systems. As products become more connected, feature-rich, and update-driven, building, deploying, and operating software over a long lifecycle becomes the key theme. This is why “software-defined everything” is the new buzzword across different hardware-centric industries.
Automakers are at the forefront of SDE through software-defined vehicles (SDVs). In the industrial world, automotive has historically often been an early adopter of new technologies and can be seen as an indicator of where these new software-defined systems are headed. According to IoT Analytics’ 140-page Software-Defined Vehicle Adoption Report 2026 (published December 2025), 45% of automotive OEMs and suppliers see SDV as their current top priority, and 80% of them have already moved or are in the process of moving to zonal car architectures, a key aspect of the SDV era. In most modern vehicle programs, the default assumption is no longer a distributed collection of independent electronic control units, but a coordinated software platform running a true SDV.
Manufacturing and specifically software-defined industrial automation (SDA) coming up. Manufacturing and industrial automation are behind automotive in terms of adoption at this point. But the IoT Analytics team has seen this shift over the last year, with key players at major industrial automation fairs like the SPS Expo making SDA a key theme. For example, Germany-based industrial automation company Siemens sees 3 key aspects of SDA: 1) standardized infrastructure, 2) virtualized control runtimes, and 3) IT-like engineering workflows.
In industrial automation more generally, virtual PLCs (vPLCs) and early discussions of CI/CD-style workflows indicate that SDA is starting to take shape.
“Software-defined automation… is really a paradigm shift.”
Dr. Horst Kayser, CEO Factory Automation at Siemens (at SPS 2025)
When comparing IoT Analytics’ research on SDVs with what we are seeing in manufacturing, we ask: “What can industrial automation (SDA) learn from SDVs?” It is important to keep in mind that industrial automation cannot simply copy automotive patterns due to very specific characteristics (e.g., determinism, safety, availability, and deep brownfield realities), but the team believes a comparison and zoom-out are warranted.
Insights from this article are derived from 2 reports:
Software-defined Vehicles Adoption Report 2026
A report detailing the adoption of software-defined vehicles, including deep dives on the software stack, specific OEM and supplier adoption strategies, and key trends and challenges.
SPS Fair 2025: The Latest Industrial Automation Trends
An event report made available to IoT Analytics’ corporate subscribers presenting a comprehensive summary of the key highlights and in-depth insights assembled by the IoT Analytics analyst team at SPS 2025.
Already a subscriber? View your reports and trackers here →
7 lessons manufacturers can learn from SDVs
Lesson 1: Consolidate computing across the stack
In practice, consolidating computing means reducing fragmentation by moving from many function-specific controllers toward fewer, more capable compute nodes that can host multiple software functions, with clearer separation between local I/O and centralized processing.
What automotive OEMs have been doing
Automakers consolidating compute while preserving safety-critical autonomy. Car OEMs have been operationalizing compute consolidation via zonal and centralized electrical/electronic (E/E) architectures that intentionally reduce the number of electronic control units (ECUs) and reorganize vehicle electronics around zones connected to a central compute unit. The SDV report highlights strong momentum behind this direction: most OEMs and suppliers reporting they have already started migrating. Further, the report links the rationale to tangible reductions in complexity: fewer controllers, simpler wiring, and improved manageability. Modularity is also a key benefit: zonal consolidation enables new software updates that can be pushed to specific zones or functions without impacting other parts of the vehicle.
At the same time, SDV implementations are not purely “everything centralized”: the report notes that a fully centralized compute can introduce too much latency for key applications, and OEM examples keep dedicated compute where deterministic performance and safety certification are critical, while consolidating the rest into zonal controllers and central orchestration.
For example, German automotive company BMW’s Neue Klasse series restructured its vehicles to an advanced zonal architecture with “SuperBrains” and zonal controllers, explicitly to balance centralized computing with distributed intelligence and deterministic communication (TSN).
What manufacturers can take away
Consolidate computing in industrial automation. As manufacturing and industrial automation take hold of SDA, there could be consolidation across PLCs, gateways, IPCs, and HMIs, potentially extending to centralized IT/edge server infrastructure for non-real-time workloads, alongside edge execution for real-time control. The industrial version will stay hybrid: hard real-time stays close to machines where determinism is non-negotiable, while higher-level software services (data pipelines, orchestration, apps) consolidate where they can be managed and updated more efficiently. The point is not “everything on one box,” but a rational placement of compute based on latency, safety, availability, and operability.
Selected evidence of early adoption in manufacturing
At SPS 2025 (November 2025), Germany-based automotive company Audi stated that it has now been consolidating and running a virtual PLC for manufacturing on an IT server in its Neckarsulm and Ingolstadt plants, running for over 6 months with 100% uptime, highlighting the benefits of virtualized runtimes on a consolidated compute (in this case, an IT server).
Lesson 2: The edge platform layer becomes very important
Central compute only works when it is coordinated by a platform layer: shared services and consistent interfaces for identity, policy, observability, packaging, deployment, and APIs. The platform is what prevents “faster hardware” from turning into “faster chaos.” Additionally, virtualization and containers can reproduce old automation silos unless they sit on top of common platform primitives.
What automotive OEMs have been doing
Automakers have built proprietary end-to-end platforms for their vehicles. In SDVs, OEMs (and a few major software suppliers) have been building vehicle platforms as end-to-end software ecosystems that sit above consolidated compute and coordinate the vehicle’s electronics, cross-domain communication, and lifecycle operations, rather than relying on a collection of loosely integrated ECU stacks. These platforms are structured as layered stacks: base software (RTOS/Linux), middleware/runtime capabilities (e.g., service discovery, policy management, message bus, container orchestration), and platform services (e.g., identity management, vehicle state APIs, OTA client, domain services) that provide consistent interfaces to applications across domains.
Further, the “platform” also extends beyond the car: it is integrated with back-end toolkits (developer, connectivity, digital services) and OTA platforms to manage packaging, rollout, and continuous improvement across the fleet, with CI/CD-style pipelines and security frameworks (e.g., Uptane) and HSM-backed mechanisms (secure boot/encryption) treated as core platform services rather than bolt-ons.
For example, Germany-based automotive company Mercedes-Benz’s MB.OS is positioned as a vehicle platform software foundation (Linux + QNX hybrid) that pairs domain/zonal architecture and centralized compute with OTA and a unified in-vehicle software stack.
What manufacturers can take away
Build platforms that unify industrial control across sites. Also in manufacturing, the platform layer is what turns control and edge apps into a coherent operational model across sites, lines, and machine variants.
Manufacturing requirements are a bit different, though. It includes deterministic telemetry, strict access control, policy enforcement, and lifecycle governance that meet industrial safety and audit expectations. In contrast to the automotive world, where each car is owned by the same OEM, factories need interoperability between different automation systems, and as such, the ecosystem and interoperability play becomes much more important.
Selected evidence of early adoption in manufacturing
France-based energy management and industrial automation company Schneider Electric positions its EcoStruxure suite explicitly as a platform stack: EcoStruxure Automation Expert, which ties into Schneider’s greater universal automation approach, is positioned as an open orchestration layer, paired with AVEVA Connect as a cloud-based historian and broader asset/engineering data services (i.e., shared services and consistent interfaces designed to reduce engineering complexity across heterogeneous systems).
Lesson 3: Decouple the software lifecycle from the hardware lifecycle
Instead of tying capabilities to a specific controller model and its replacement cycle, software-defined architectures aim to make control functions portable. The key shift is that a stable base layer and middleware provide a consistent execution environment, so complex functions can be deployed, moved, and updated across central computers or zone controllers without rewriting the application each time the underlying hardware changes.
What automotive OEMs have been doing
Efforts to decouple software from vehicle hardware. Automakers are building SDV stacks where hardware abstraction, hypervisors, and middleware/runtime services (e.g., container orchestration, policy management, service discovery, message bus) reduce hardware coupling and enable flexible placement of software workloads across the E/E architecture. This is also why suppliers emphasize that software placement in SDVs becomes more flexible, as platform isolation and standardized runtime services make relocation feasible. In parallel, OEMs have used this decoupling to roll out and even monetize functions after delivery; for example, US-based EV company Tesla’s “Acceleration Boost” as a paid software change without hardware modification.
“With SDVs, it doesn’t matter where in the car which software is deployed. Each app gets its own dedicated space on the chip.”
Engineer at NXP (at Embedded World 2025)
What manufacturers can take away
Software portability enables software-enabled upgrades in manufacturing. The industrial parallel to SDV’s decoupling of hardware and software is increasingly expressed through license-based feature activation and modular software options: machines ship with a stable runtime/middleware foundation, and additional capabilities (control functions, optimizers, diagnostics) can be enabled later as deployable, versioned modules, all without forcing a hardware refresh. This requires clear compatibility boundaries plus a runtime layer that stays stable as hardware changes, enabling modernization and upgrades on a software cadence rather than a hardware cadence.
Selected evidence of early adoption in manufacturing
US-based industrial automation company Rockwell Automation’s Logix Edge positions the Logix control engine as a software workload on an industrial PC, designed to coexist with HMI/IoT functions and even customer workloads (e.g., AI/vision) on the same hardware—an explicit step toward portability and decoupling control from dedicated controller boxes. More broadly, SPS observations describe edge software increasingly being packaged as “portable, hardware-agnostic workloads” that can run across controllers, IPCs, and gateways using mainstream IT deployment practices, which is the kind of foundation “function on demand” depends on.
Lesson 4: DevOps and toolchains bring “software-defined” to life
In practice, “software-defined” only becomes repeatable when engineering and operations are supported by a software factory: repositories, automation, simulation, testing, and release governance that make change low-friction and auditable.
What automotive OEMs have been doing
Automakers have invested heavily into IT-like DevOps toolchains for SDV delivery. Automotive OEMs have explicitly included model-based systems engineering, variant management, DevOps repositories, virtual ECU simulation, test automation, release & compliance, and continuous integration/continuous delivery (CI/CD) orchestration in the SDV reference tech stack. The Software-Defined Vehicle Adoption Report describes modern DevOps pipelines that build OS images, run software-in-the-loop- and hardware-in-the-loop-style tests, and deliver signed images to OTA platforms supported by digital twins and virtual ECUs; i.e., toolchain maturity is part of the core SDV implementation model rather than an add-on.
OEMs such as Germany-based automotive company Volkswagen are adopting cloud-based DevOps toolchains that support CI/CD plus SIL/HIL validation using virtual ECUs and high-performance computing, making toolchains a core part of how vehicle software is built and released. At AWS re:Invent 2025, Japan-based automotive company Nissan shared that the company uses AWS for CI process automation and reportedly achieved 75% execution time reduction relative to the company’s original on-premises environment.
Slide showing Nissan’s integration SIL pipeline and results from its use of AWS to automate CI processes (source)
What manufacturers can take away
Say goodbye to one-off hardware engineering and hello to true IT-like DevOps. SDA programs will scale only if engineering becomes repeatable and testable in an IT-like way, without ignoring real-time and safety constraints. Variant management matters in automation because machine builders and end users live in option trees: machine configurations, customer-specific requirements, and long-lived product lines. Simulation and virtual commissioning serve as the industrial analogue to virtual ECUs: they are critical for validating changes before going to production. Further, CI/CD in control contexts must be explicitly defined: deterministic testing gates, plant-/hardware-in-the-loop equivalents where needed, and a release process that operational teams can trust.
Selected evidence of early adoption in manufacturing
Austria-based furniture movement system manufacturer GRASS GmbH adopted Version Control from US/Germany-based industrial software company Software Defined Automation to help the former manage its PLC software code. Version Control helped GRASS quickly identify who made what changes and when, which reportedly enabled greater traceability and accountability throughout the PLC development lifecycle.
Meanwhile, Germany-based robotics software company voraus robotik is applying IT DevOps principles to the robotics space. Its development environment (voraus.pioneer) emphasizes developing, simulating, and automated testing with modern software tools, aiming to shift robotics/automation work away from late-stage, on-hardware commissioning and toward repeatable CI/CD-style workflows.
Lesson 5: OTA is a game-changer
Over-the-air (OTA) means updating the software of connected equipment remotely, without sending a technician on-site or taking hardware to a service center. Instead of “installing by hand,” updates are packaged, verified, rolled out to a limited set first, monitored for issues, and rolled back if something goes wrong so changes can be delivered faster while still staying under control.
What automotive OEMs have been doing
Automakers are expanding OTA well beyond infotainment and using it as a practical lever for both cost avoidance and continuous product improvement. On the cost side, OTA increasingly functions as a “remote recall” mechanism: when the remedy is software, OEMs can deploy fixes directly to vehicles at scale, which reduces dealer visits, downtime, and service logistics (e.g., Tesla’s large Autosteer-related recall has been addressed via an OTA software remedy, explicitly framed as not requiring a service appointment). On the user-experience side, OTA has become the pathway to make vehicles better after purchase, shipping new functions, refinements, and usability improvements as part of routine software releases (e.g., Germany-based automotive company BMW’s Remote Software Upgrade positioning emphasizes delivering “newest functions and features” via OTA).
What manufacturers can take away
Stop treating software updates like rare maintenance events. Traditionally, updating and maintaining industrial hardware required a shutdown and a technician with a USB stick, if the hardware is even updated at all. Programmatically turning updates into a controlled, routine process helps engineers validate changes on a test system or pilot cell first, roll them out gradually (cell-by-cell or line-by-line), and only expand once the update behaves as expected. When something goes wrong, you need a fast way to revert to the last known-good version, so the issue becomes a rollback, not a production stop. Done well, this avoids the “all-or-nothing” update moment that puts a factory at risk, while still making it realistic to keep assets secure and up to date over time.
Selected evidence of early adoption in manufacturing
At SPS 2025, Switzerland-based measurement instrumentation and automation technology company Endress+Hauser framed SDA as a response to a “broken reality” where plants lack transparency on what firmware is running and still rely on USB sticks to deploy updates. The company advocated an “App Store” model for asset management to enable modular, vendor-agnostic lifecycle management (e.g., mixing fleet management from one vendor with security from another).
Lesson 6: End-to-end security and compliance become its own discipline
Software-defined architecture expands the attack surface and increases change frequency, so security shifts from “perimeter hardening” to lifecycle governance: design-time controls, secure delivery, runtime monitoring, and evidence for audits and regulation.
What automotive OEMs have been doing
Automakers have made SDV security its own lifecycle operations. Security in SDVs has increasingly become a governed lifecycle discipline, shaped by both regulation and the practical realities of continuous software updates. UN R155 and UN R156 require a cybersecurity management system and secure software update management for type approval, while ISO 21434 provides the lifecycle framework for cybersecurity risk management across vehicle electronics and software.
Rather than treating security as a deployment-time check, automotive OEMs are embedding security controls into the development and release process through compliance-aware pipelines and repeatable evidence generation, and by operationalizing software and hardware bills of materials (SBOMs/HBOMs) discipline and vulnerability management that ties software components to known common vulnerabilities and exposures (or CVEs).
For example, the OEM group Renault-Nissan-Mitsubishi Alliance is operationalizing post-deployment vehicle security through dedicated vehicle security operations, ingesting signals from telematics, OTA, diagnostics, and APIs to detect and respond to fleet-scale threats.
What manufacturers can take away
Develop similar security practices to those in SDVs. The compliance dynamic applies to SDA once updates and open software ecosystems become normal. The platform must provide end-to-end mechanisms for identity, access control, signing and verification, policy enforcement, observability, vulnerability management, and incident response. It must also do so in a way that satisfies operational and audit expectations.
The practical playbook looks familiar as with SDVs: SBOM discipline and vulnerability management, compliance-aware pipelines with evidence generation, and runtime monitoring tied to a clear incident response model. If SDA wants SDV-style update velocity, it needs SDV-level security mechanics, adapted to industrial safety and operational constraints.
How regulations are influencing security adoption in manufacturing
The EU Cyber Resilience Act (CRA) is poised to have a significant impact on manufacturing in terms of implementation costs and severity of punishments, particularly for EU manufacturers and foreign manufacturers operating in the EU, according to IoT Analytics’ Digital and ESG Regulations Outlook 2025–2030 report (published August 2025). The CRA’s vulnerability-handling requirements explicitly include identifying and documenting software components and vulnerabilities by preparing an SBOM in a commonly used, machine-readable format that covers at least the top-level dependencies, something manufacturers must be able to provide as part of technical documentation and to market surveillance authorities when requested. This becomes operationally urgent because reporting obligations begin before full implementation of the regulation: from 11 September 2026, manufacturers must report actively exploited vulnerabilities and severe incidents via the CRA’s single reporting platform, with an early warning within 24 hours and follow-up information within 72 hours. These deadlines would be difficult to meet without an SBOM-backed component inventory and continuous vulnerability monitoring.
Lesson 7: AI impact is only seen once the software-defined foundation exists
AI can automate parts of engineering and operations only when the underlying toolchain, data access, and lifecycle controls are sufficiently structured to constrain actions, verify outputs, and keep humans in the loop when required.
What automotive OEMs have been doing
Automakers deploying AI to accelerate SDV engineering workflows. SDV teams are applying AI most pragmatically where it fits into established engineering workflows, especially requirements work, code generation and refactoring support, and test automation acceleration. The research for the Software-Defined Vehicles Adoption Report 2026 found 3 key areas where generative AI specifically plays key engineering roles:
1. Requirements engineering and testing
“GenAI can be very useful in optimizing the design and testing phases of SDVs, particularly by addressing conflicting requirements and improving the functional sequencing of tests. By identifying conflicts in requirements early, GenAI helps prevent issues that could arise during system integration. Additionally, GenAI assists in the functional sequencing of testing, such as in ECU software testing, ensuring that the design and testing processes are aligned with technical requirements.”
Senior program manager, connected vehicle services at a leading European car OEM
2. Code generation, testing, and report generation
“The first and most prevalent use case is assisting software engineers, particularly in code generation and assisting with the creation of tests from requirements. Translating requirements into executable tests and generating formal test cases from technical specifications are also significant use cases for GenAI. In addition, GenAI can help in generating reports, extracting relevant information from large databases, and debugging systems by making smart queries into patterns.”
Executive chief architect at a leading American car OEM
3. Requirements engineering and skeleton design
“System engineering involves understanding the requirements and deciding how to develop each requirement or function, whether it’s with hardware, software, or a combination of both. Understanding conflicting requirements, which are common among different OEMs, is crucial. This process can be time-consuming due to the complexity involved. GenAI provides a significant advantage in comprehending various requirements and ensuring their alignment. One more use case GenAI is enabling in systems engineering is designing the skeleton of the system. For example, when you develop an ECU, system requirements that are written on it need to be translated to technical requirements, which is helpful in the overall design of the system.”
Executive program director of advanced safety and user experience at a major automotive technology provider
What manufacturers can take away
Prioritize software-defined architectures before going all-in on AI. For manufacturers, agentic concepts will only scale when there is a stable foundation of standardized engineering environments, trusted data flows, and lifecycle governance that can enforce validation gates. At SPS, the IoT Analytics team observed early signals of how this could look, with demonstrations from several vendors of autonomous engineering workflows that generate control applications from user specifications and then use simulation and testing to validate outcomes before deployment.
Selected evidence of early adoption in manufacturing
Across all of IoT Analytics’ market research, markets related to industrial data foundations have seen vast growth over the last 2 years, with continued expansion across these markets expected through the rest of the decade. For instance, according to IoT Analytics’ Industrial Connectivity Market Report 2024–2028, the industrial data ops market experienced 89% growth between 2023 and 2024 and is expected to grow at 49% CAGR between 2024 and 2028. Further, according to IoT Analytics’ Data Management and Analytics Market Report 2024–2030, the data architecture market was valued at nearly $21 billion in 2024 and is forecasted to reach $55.2 billion by 2030 (18% CAGR).
Analyst takeaway: What automation decision-makers should borrow, adapt, and avoid
IoT Analytics Senior Analyst Harsha Anand performed the majority of the analyses in the Software-Defined Vehicle Adoption Report 2026, while IoT Analytics CEO Knud Lasse Leuth and 3 other analysts attended SPS 2025. Below are practical actions for automation decision-makers that want SDV-like software speed without breaking production.
Borrow
- Build a platform layer, not just virtualized applications. Standardize identity/access, logging/telemetry, configuration management, and APIs across hardware so deployments don’t become one-offs.
- Run automation engineering like software engineering. Put control projects in version control, enforce reviews, automate builds, and make simulation/virtual commissioning a default gate before deployment.
- Automate compliance evidence. Generate SBOMs and release records as part of the build/release process so audits do not become manual fire drills.
- Make updates a managed process. Treat rollback, staged rollout, and “last known good” as mandatory capabilities (not nice-to-haves).
- Institutionalize SBOM + vulnerability management. Maintain an inventory of software components and continuously track exposure to CVEs.
Adapt
- Keep determinism where it matters. Orchestrate around real-time constraints; don’t assume cloud patterns fit control loops.
- Design for brownfield coexistence. Assume mixed-vendor PLCs and long asset lifetimes; create migration paths that don’t require “rip and replace.”
- Bake in safety constraints. Align the release process with the realities of safety certification (testing depth, approvals, documentation), and define what can be updated without re-certification.
Avoid
- Jumping on the AI train before the software-defined foundation is in place. If toolchains, data access, and validation gates are not standardized, AI outputs become hard to verify, amplifying inconsistency and operational risk rather than reducing engineering effort.
- Containerizing an application and calling it done. Without platform services, governance, and rollback, you just move complexity into a new wrapper.
- Treating security as an add-on after enabling remote access and updates. Once software is updatable and connected, the update pipeline and APIs become part of the attack surface, so identity, signing, vulnerability management, and monitoring must be built in from day one.
- Big-bang updates. Avoid plant-wide rollouts without pilots, gates, and reversibility.
OEMs increasingly prioritize software-defined automation (Insights+)
Below are 3 software trends from IoT Analytics’ SPS Fair 2025: The Latest Industrial Automation Trends event report.
Access key market data for $99/month per user
The Insights+ Subscription unlocks exclusive facts & figures. You will gain access to:
- Additional analyses derived directly from our reports, databases, and trackers
- An extended version of each research article not available to the public
Full report access not included. For enterprise offerings, please contact sales: sales@iot-analytics.com
Disclosure
Companies mentioned in this article—along with their products—are used as examples to showcase market developments. No company paid or received preferential treatment in this article, and it is at the discretion of the analyst to select which examples are used. IoT Analytics makes efforts to vary the companies and products mentioned to help shine attention on the numerous IoT and related technology market players.
It is worth noting that IoT Analytics may have commercial relationships with some companies mentioned in its articles, as some companies license IoT Analytics market research. However, for confidentiality, IoT Analytics cannot disclose individual relationships. Please contact compliance@iot-analytics.com for any questions or concerns on this front.
More information and further reading
Sign up for our research newsletter and follow us on LinkedIn to stay up-to-date on the latest trends shaping the IoT markets. For complete enterprise IoT coverage with access to all of IoT Analytics’ paid content & reports, including dedicated analyst time, check out the Enterprise subscription.
Already a customer?
Register for our monthly research readout. This edition features the Software-defined Vehicles Adoption Report 2026. Join Knud Lasse Lueth (CEO), Satyajit Sinha (Principal Analyst), and Harsha Anand (Senior Analyst) as they provide expert commentary.
