Functional Safety Data Processing with Security Level Attributes

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Developing functionally safe electrical, electronic, and programmable electronic systems that meet stringent safety integrity levels (SIL) requirements is costly and complex, especially when systems consist of sub-systems with different security levels, as existing methods struggle to ensure independence and data integrity across varying security levels.

Innovation Solution

A method and device that process and transfer data within a system composed of sub-systems with secure hardware and software components, where each sub-system adds an identification attribute to data indicating its security level, allowing the system to recognize and process data at the lower of two security levels if they differ, ensuring functional safety without increasing technical effort.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Adaptability or versatility

If subsystems with different security levels are integrated into a single system, then system versatility and adaptability are improved, but ensuring data integrity and independence between security levels becomes more complex

Engineering Contradiction:
Improvesystem adaptabilityVSAvoidsystem complexity
Core Design Contradiction:
Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The system is segmented into multiple subsystems, each operating at a specific security level. Each subsystem independently processes data according to its security level, with clear boundaries between them. The data processing path is divided into separate channels for different security levels, ensuring independence while allowing integration of diverse security requirements.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

Different security levels are applied locally to different subsystems rather than requiring the entire system to operate at the highest security level. Each subsystem is configured with the appropriate security level matching its functional requirements, allowing high-security components to coexist with standard components without unnecessary complexity throughout the entire system.

Inventive Principle:
Principle #3Local quality

2Reliability

If the entire software is treated as safety-related to ensure safety functions, then safety integrity is improved, but development effort and costs increase significantly

Engineering Contradiction:
Improvesafety integrityVSAvoiddevelopment effort
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The software is segmented into safety-related modules and non-safety modules. Only the safety-related modules are developed and certified according to IEC 61508 standards, while non-safety modules follow standard development practices. This segmentation allows the system to achieve required safety integrity without applying stringent safety requirements to the entire software base.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

Safety-related requirements are applied locally only to the specific software modules that perform safety functions, rather than uniformly across all software. This allows standard development methods to be used for non-critical modules while maintaining high safety standards for critical safety functions, reducing overall development effort.

Inventive Principle:
Principle #3Local quality

3Reliability

If multiple channels are used to achieve higher safety integrity levels, then safety reliability is improved, but system complexity and resource requirements increase

Engineering Contradiction:
Improvesafety reliabilityVSAvoidsystem complexity
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The system uses segmentation to create independent processing channels for different security levels. Each channel processes data appropriate to its security level, providing redundancy and independence without requiring full multi-channel architecture throughout the entire system. This reduces the complexity overhead of multi-channel systems.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

Instead of implementing full multi-channel redundancy across all system functions, the patent applies multi-channel principles only partially to the specific functions that require high safety integrity. Standard single-channel processing is used for non-critical functions, reducing overall system complexity while maintaining adequate safety for critical operations.

Inventive Principle:
Principle #16Partial or excessive action

Data Source

PatentEP3271856B1Method and device for processing and transmitting data within a functionally secure, electrical, electronic and/or programmable electronic system
Publication Date: 2021.02.17 PHOENIX CONTACT GMBH & CO KG
  • EP3271856B1 patent drawingFigure 1
  • EP3271856B1 patent drawingFigure 2
  • EP3271856B1 patent drawingFigure 3

AI summary

The invention relates to the processing and transmitting of data within a functionally secure, electrical, electronic and/or programmable electronic system that is formed by at least two sub-systems, which each comprise at least one secure hardware and/or software component, and each satisfy a determined security level for a functionally secure data processing. The invention provides: the processing of data by means of the secure hardware and/or software component of a first of the sub-systems to form functionally secure data of a first security level; and the adding of at least one characterisation attribute to this data via said first sub-system, which characterisation attribute characterises the suitability of the data for the use of this first security level; the transmitting of the data including the added characterisation attribute from the first sub-system to a second of the sub-systems; and receiving the data including the added characterisation attribute via the second sub-system; and the checking of the received characterisation attribute via the second sub-system by means of the secure hardware and/or software component thereof for the purpose of determining whether the security level, characterised by this characterisation attribute, is equal or unequal to the security level satisfied by the second sub-system; and, if the check results in an inequality, the functionally secure further processing of the data based on the reduced security level.