• Not Answered

Alignment of IQ Software Defined Strategy with Future PK Architecture

With Emerson introducing the software defined IQ Controller via v16, it clearly reflects a strategic shift toward virtualized control architectures.

Given this direction, how should users interpret the long-term roadmap for PK class control? Is there an expectation that PK will remain hardware-based, or could it eventually transition toward a similar software defined model?

From an adoption standpoint, how should users factor this into decisions today, particularly to avoid potential re-architecture or additional upgrade cycles if PK evolves in the same direction?

Vincent J. Scurria

• 14 May 2026 4:24 PM
• Cancel

4 Replies

• David-m.walker

  

  • 15 May 2026 6:07 AM

  I don't see us moving away from a hardware solution, such as the PK, for a long time. One key aspect, for my customers, is that the PK has a lifecycle of many years (MQ has been around for over 20 years). The IQ controller, running (for now) on Dell Servers, have a lifecycle of around 5 years.
  
  Support for M and S-series continues.
  
  You can use the PK Flex today, with software defined control, or the PK with perpetual licensing.
  
  Disclaimer - I work for Emerson:

  • Cancel
• Vincent J. Scurria

  

  • 15 May 2026 1:49 PM

  In reply to David-m.walker:

  Thanks David, helpful perspective, especially on lifecycle and customer expectations around hardware stability.
  
  I agree the PK/M-series longevity is a major factor today, particularly for sites prioritizing deterministic performance and long lifecycle assets. That said, most new projects are already trending toward S-series or newer architectures, which reflects an ongoing evolution in the control layer.
  
  What Emerson is signaling with the IQ controller feels less like a near-term replacement and more like a directional shift toward software-defined architectures. Even if PK remains hardware based for the foreseeable future, it raises some broader questions around where future innovation and capability will be anchored.
  
  One point I wanted to clarify from your comment, when you reference the ~5-year lifecycle for IQ, is that tied primarily to the underlying server hardware refresh rather than the control application itself?
  
  From a software defined standpoint, I would expect the control layer to be largely decoupled from hardware, with migration across infrastructure being relatively transparent.
  
  Where this becomes important from a user perspective is understanding how “transparent” that refresh really is in practice, particularly in OT environments, where even infrastructure changes can carry validation, downtime, or performance implications.
  
  That distinction has a significant impact on how we think about long term architecture decisions and the relative tradeoffs with PK class controllers.
  
  Curious how Emerson is thinking about that balance between hardware lifecycle and software abstraction over time.

  • Cancel
• David-m.walker

  

  • 18 May 2026 3:44 AM

  In reply to Vincent J. Scurria:

  A couple of points to clarify here:
  
  PK/M-Series is a proven solution and will be (I hope) for a long time. I have many customers with installed systems that will want to maintain the Traditional I/O path. Many customers will want to, as you point out maintain determinism, segregation and long lifecycle.
  
  For the IQ lifecycle, my comment was more about the lifecycle of the host servers, not the actual IQ controller. I can already drag and drop a configuration from a PK/M-Series into an IQ, and I can move virtual workstations and embedded nodes in a virtualized environment. It's just the hosts that have a different lifecycle, which is why I hope the roadmap has non-Dell hosts for the IQ.
  
  Today I see great benefit from the IQ in simulation systems, digital twins and training systems.
  
  The balance between hardware lifecycle and software abstraction depends on hardware direction - given the challenge with computer components we may all be running control in the cloud soon ;-)

  • Cancel
• Vincent J. Scurria

  

  • 18 May 2026 10:22 PM

  In reply to David-m.walker:

  Thanks David, appreciate the additional clarification.
  
  That helps differentiate the infrastructure lifecycle from the control layer, which is an important distinction. From a user standpoint, the key consideration will be how “transparent” those infrastructure refreshes are in practice, particularly in OT environments where validation, downtime, and performance risk still need to be managed.
  
  As these architectures evolve, understanding how that is handled at scale will be important in shaping long term design decisions.
  
  Appreciate the perspective

  • Cancel