Modular Software Management for Electrical Switching Devices

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Current electrical switching devices with embedded software modules face challenges in modularity and real-time operation, limiting user flexibility and safety, as existing modular architectures either compromise real-time performance or are too rigid for dynamic functionality changes.

Innovation Solution

A method and device that utilize modular software modules with service contracts, allowing dynamic installation and verification of software modules on an embedded electronic computer, ensuring compliance with real-time constraints through a management system that verifies execution and implements recovery strategies to maintain safety and security.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Adaptability or versatility

If a modular software architecture is implemented to allow dynamic installation and uninstallation of individual functions, then user flexibility and adaptability are improved, but ensuring real-time operation and system safety becomes more difficult

Engineering Contradiction:
Improvesoftware modularityVSAvoidreal-time operation
Core Design Contradiction:
Adaptability or versatilityVSReliability

Solution Approach 1:

The software system is divided into independent functional modules that can be individually installed, uninstalled, and managed. Each module is encapsulated with a service contract that defines its resource requirements and operational constraints, allowing modular deployment while maintaining system integrity and real-time performance through structured organization.

Inventive Principle:
Principle #1Segmentation

2Ease of operation

If software modules are made independent and dynamically installable, then ease of operation and user flexibility are improved, but system complexity and verification requirements increase

Engineering Contradiction:
Improvedynamic module installationVSAvoidmodule verification
Core Design Contradiction:
Ease of operationVSDevice complexity

Solution Approach 1:

Service contracts are established in advance for each software module, pre-defining hardware resource requirements, operational parameters, and compliance criteria. This preliminary structuring enables automated verification during module installation and execution, reducing the complexity of runtime verification while maintaining ease of dynamic module management.

Inventive Principle:
Principle #10Preliminary action

3Reliability

If fixed sets of predefined functionalities are used in a monolithic architecture, then system safety and real-time performance are maintained, but user flexibility and adaptability are reduced

Engineering Contradiction:
Improvereal-time performanceVSAvoidfunctionality selection
Core Design Contradiction:
ReliabilityVSAdaptability or versatility

Solution Approach 1:

The system transitions from a static monolithic architecture to a dynamic modular architecture where functional modules can be selectively activated or deactivated based on user needs. The service contract mechanism ensures that dynamic module selection does not compromise real-time performance, as each module's resource consumption is pre-defined and monitored according to its contract.

Inventive Principle:
Principle #15Dynamics

Data Source

PatentUS10839088B2Method for managing embedded software modules for an electronic computer of an electrical switching device
Publication Date: 2020.11.17 SCHNEIDER ELECTRIC IND SAS
  • US10839088B2 patent drawing
  • US10839088B2 patent drawing
  • US10839088B2 patent drawing

AI summary

A method for managing embedded software modules for an electronic computer embedded in an electrical switching device for switching an electric current includes acquiring a software module including a runnable code and a service contract declaring the hardware resources required by the runnable code when it is run by the computer; installing the software module inside a host receptacle intended to form an environment for running a software module and including a memory location defined statically inside a memory of the computer and being associated with a subset of hardware resources of the computer; running the software module including a step consisting in verifying whether the operation of running of the software module respects the service contract, the running operation being allowed to continue if the service contract is respected and, otherwise, a recovery step is implemented in order to interrupt the running operation.