Actor-Based Messaging for Fault-Tolerant Robotic Workflows

Resolve Bottlenecks,
Find Innovative SolutionsGenerate Solutions

Solution Overview

Problem

Existing communication mechanisms between scheduling software and third-party software on different computing platforms are prone to errors, crashes, and hangs, leading to instability and latency in automated workflows, with no effective strategies for handling software restarts or integrating systems with different software specifications.

Innovation Solution

A remote actor-based model is implemented as a communications structure between scheduling and third-party software, using a client-side local proxy and server-side remote proxy to enable seamless messaging across platforms, hiding protocol complexities and allowing for efficient restarts of third-party software without disrupting workflows.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If traditional communication protocols (RS-232, TCP/IP, Windows service) are used to communicate between scheduling software and third-party software on different computing platforms, then communication can be established, but the system becomes complex, error-prone, and unstable due to fundamental differences between computing platforms

Engineering Contradiction:

Improvecommunication stabilityVSAvoidcommunication mechanism complexity

Core Design Contradiction:

ReliabilityVSDevice complexity

Solution Approach 1:

The patent introduces an intermediary communication layer that abstracts platform-specific protocols into a unified messaging interface. This mediator handles the complexity of cross-platform communication internally, allowing scheduling software and third-party software to interact through standardized messages without directly implementing platform-specific protocols like RS-232 or TCP/IP.

Inventive Principle:

Principle #24Intermediary (Mediator)

Solution Approach 2:

The communication system is segmented into distinct layers: a platform-independent messaging layer and platform-specific implementation layers. This segmentation isolates the complexity of different computing platforms into separate modules, allowing the core scheduling software to remain simple while handling platform diversity through modular adapters.

Inventive Principle:

Principle #1Segmentation

2Adaptability or versatility

If third-party software is integrated directly with scheduling software, then functionality is extended, but the system becomes unstable due to software crashes, hangs, and security vulnerabilities in third-party components

Engineering Contradiction:

Improvethird-party integration capabilityVSAvoidsystem stability

Core Design Contradiction:

Adaptability or versatilityVSReliability

Solution Approach 1:

A mediator layer is introduced between scheduling software and third-party software, providing isolation and controlled interaction. This mediator validates messages, handles errors gracefully, and prevents crashes in third-party software from propagating to the core scheduling system, thereby maintaining stability while enabling integration.

Inventive Principle:

Principle #24Intermediary (Mediator)

Solution Approach 2:

The system implements error handling and validation mechanisms in advance of actual failures. Message validation, timeout handling, and exception catching are built into the communication protocol beforehand, cushioning the system against crashes and hangs from third-party software before they can cause system-wide instability.

Inventive Principle:

Principle #11Beforehand cushioning (Prior cushioning)

3Adaptability or versatility

If existing communication mechanisms are used across different computing platforms, then platform diversity is supported, but latency increases and performance decreases due to protocol complexity and error handling overhead

Engineering Contradiction:

Improvecross-platform compatibilityVSAvoidworkflow execution speed

Core Design Contradiction:

Adaptability or versatilityVSProductivity

Solution Approach 1:

Instead of implementing complex real-time protocol handling, the system uses asynchronous message passing where messages are copied and queued between platforms. This copying approach eliminates blocking operations and protocol negotiation overhead, allowing parallel processing to continue while messages are transmitted, thereby reducing latency.

Inventive Principle:

Principle #26Copying

Solution Approach 2:

Messages are prepared and validated in advance before transmission, and communication channels are pre-established between platforms. This preliminary action reduces runtime overhead and avoids last-minute protocol negotiations that would cause latency, enabling faster workflow execution across different computing platforms.

Inventive Principle:

Principle #10Preliminary action

Data Source

PatentUS12632322B2Actor-based framework for communication between software systems following third-party failure

Publication Date: 2026.05.19 BIOSERO INC

AI summary

A software framework for implementation in the performance of automated robotic workflows establishes a peer-to-peer communications structure between applications operating on different computing platforms within the same workflow environment. The software framework instantiates a messaging protocol within a remote actor-based model that separates server-side activity that includes third-party software controlling third-party instruments from client-side activity that includes scheduling software controlling workflows within the automated workflow environment. This framework promotes continuous messaging across the different computing platforms and enables a restart of the third-party software following an exception or fail state experienced by the server-side workflow elements without interruption to the automated workflow environment.