Flow RTU Modular Software Architecture for Independent Updates

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Current flow computer software and RTU software are monolithic, requiring a complete update and extensive testing for even minor changes, leading to unintended consequences and inefficient resource management.

Innovation Solution

A modular software architecture for flow computers with an enablement framework that allows individual application instances to be managed separately, enabling independent updates and resource allocation, and supports add-ons for enhanced functionality.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Ease of manufacture

If monolithic software architecture is used, then system integration is simplified, but software updates require complete re-release and extensive testing

Engineering Contradiction:
Improvesoftware update efficiencyVSAvoidtesting time
Core Design Contradiction:
Ease of manufactureVSLoss of time

Solution Approach 1:

The software is divided into separate application instances (e.g., billing application, inventory application, customer service application) that can be independently updated and deployed. Each application instance operates as a distinct module within the monolithic system, allowing selective updates without requiring complete system re-release or extensive regression testing of unrelated components.

Inventive Principle:
Principle #1Segmentation

2Device complexity

If monolithic software architecture is used, then system structure is simple, but risk of unintended consequences from updates increases

Engineering Contradiction:
Improvesoftware structure complexityVSAvoidsoftware update reliability
Core Design Contradiction:
Device complexityVSReliability

Solution Approach 1:

By segmenting the software into independent application instances, the patent isolates update risks to specific modules. When one application is updated, other applications remain unaffected and continue operating normally, reducing the risk of system-wide failures and unintended consequences from software updates.

Inventive Principle:
Principle #1Segmentation

3Adaptability or versatility

If custom host software is used for communication and visualization, then system functionality is enhanced, but maintenance and synchronization burden increases

Engineering Contradiction:
Improvecommunication and visualization capabilityVSAvoidsoftware maintenance effort
Core Design Contradiction:
Adaptability or versatilityVSEase of operation

Solution Approach 1:

The patent implements a standardized communication framework that provides universal communication and visualization capabilities across all application instances. This framework handles data exchange, device communication, and visualization tasks uniformly, eliminating the need for separate custom host software for each application and reducing maintenance synchronization efforts.

Inventive Principle:
Principle #6Universality (Multi-functionality)

Data Source

PatentEP4711926A1Flow computer remote terminal unit with modular software architecture
Publication Date: 2026.03.18 ABB (SCHWEIZ) AG
  • EP4711926A1 patent drawingFigure 1
  • EP4711926A1 patent drawingFigure 2
  • EP4711926A1 patent drawingFigure 3

AI summary

A method includes executing, by a flow remote terminal unit (RTU) management system, a plurality of application instances that manage one or more industrial operations at an industrial facility; and receiving, from one or more input devices at the industrial facility and by an enablement framework of the RTU management system, input device information associated with the one or more industrial operations. The enablement framework manages the plurality of applications instances being executed by the flow RTU management system, and the enablement framework is partitioned separately in memory from the plurality of application instances. The method also includes determining, based on using a dispatcher of the enablement framework, one or more application instances, from the plurality of application instances, that utilize the input device information; and providing, by the dispatcher of the enablement framework, the input device information to the determined one or more application instances.