Hierarchical Software Bus for Multitasking Communication

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Existing communication systems between software modules are not suitable for multitasking environments, particularly for processes, lightweight processes, and tasks, as they lack adaptability to different levels of parallelism and machine-to-machine communication.

Innovation Solution

A hierarchical communication system using a software bus with mechanisms for message exchange between client tasks, incorporating a proprietary scheduler, FIFOs, and relay tasks to facilitate communication across processes and machines, ensuring adaptability to the multitasking level of transmitter and receiver modules.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Adaptability or versatility

If existing communication systems are used between software modules, then communication between processes is possible, but they are not suitable for multitasking environments and lack adaptability to different levels of parallelism

Engineering Contradiction:
Improveadaptability to different levels of parallelismVSAvoidcommunication system complexity
Core Design Contradiction:
Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The communication system is segmented into multiple levels corresponding to different software module types (processes, lightweight processes, tasks). Each level has its own communication mechanisms and FIFO queues, allowing the system to adapt to the appropriate level of parallelism without requiring a complete redesign for each scenario.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The software bus is designed as a universal communication system that can handle communication between any type of software module (processes, lightweight processes, tasks) through a unified interface. The bus management module automatically determines the appropriate communication path based on the module types involved, providing multi-functionality without requiring separate dedicated systems for each module type.

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

2Productivity

If message copying is performed across all communication paths, then communication between any software modules is enabled, but the number of message copies increases

Engineering Contradiction:
Improvecommunication efficiencyVSAvoidmessage copying overhead
Core Design Contradiction:
ProductivityVSLoss of substance

Solution Approach 1:

The system applies different message passing strategies based on the local relationship between sender and receiver. When both modules are at the same level (e.g., both are tasks), messages are passed directly through shared FIFO queues without copying. When modules are at different levels or across process boundaries, relay tasks are used to minimize copies by intelligently routing messages through the hierarchy.

Inventive Principle:
Principle #3Local quality

Solution Approach 2:

Relay tasks serve as intermediary entities that facilitate communication between software modules at different levels of the hierarchy. Instead of copying messages through multiple levels, the relay task receives the message once and forwards it to the appropriate destination, reducing the total number of message copies while enabling communication across process and task boundaries.

Inventive Principle:
Principle #24Intermediary (Mediator)

3Ease of operation

If a unified programming interface is provided for all software modules, then ease of operation is improved, but the underlying complexity of handling different module types increases

Engineering Contradiction:
Improveprogramming interface simplicityVSAvoidmodule type handling complexity
Core Design Contradiction:
Ease of operationVSDevice complexity

Solution Approach 1:

The bus management module automatically determines the appropriate communication path and handles the complexity of different module types without requiring programmer intervention. The unified programming interface allows software modules to communicate using simple send/receive operations, while the bus management module self-services by routing messages appropriately based on the module hierarchy and types involved.

Inventive Principle:
Principle #25Self-service

Data Source

PatentEP2791798B1Software bus
Publication Date: 2020.09.30 SAGEMCOM BROADBAND SAS
  • EP2791798B1 patent drawingFigure 1
  • EP2791798B1 patent drawingFigure 2
  • EP2791798B1 patent drawingFigure 3~4

AI summary

The present invention relates to the field of methods of communication between software modules and more particularly software buses. There is described a software bus which allows communication between software modules. This communication occurs within a machine and between machines and operates interchangeably for the software module whether one is dealing with a process, a lightweight process or a simple task. The communication relies on mechanisms adapted to the multitask level at which the sender and receiver software modules operate. It is based on a hierarchical architecture, phases of discovery and of recording of the various software modules having to communicate via the bus.