Software Updates in Dual Safety-Critical Distributed Systems
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Operating safety-critical systems, such as train protection and interlocking systems, poses challenges due to the difficulty in updating software without compromising security, as existing methods require extensive testing and approval procedures, and automatic system shutdown upon detected changes.
Innovation Solution
A method involving a first data device with approved safety-relevant software and a reference data device with the same software, where the first device can be updated with non-safety-related software, and both devices' output checked for consistency before data is shared, allowing updates without re-approval by ensuring safety-related data matches across a qualified majority of devices.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If software updates are performed in safety-critical systems after approval, then software functionality and security can be improved, but the system requires extensive testing and re-approval procedures which reduce productivity
Solution Approach 1:
The patent segments software into safety-relevant and non-safety-relevant components. Safety-critical software remains unchanged and approved, while non-safety-relevant software can be updated independently. This segmentation allows updates to proceed without triggering full re-approval processes, resolving the contradiction between maintaining security and improving update efficiency.
Solution Approach 2:
The patent introduces a reference data device as an intermediary that stores the originally approved software state. A comparison device acts as a mediator to verify that updates to non-safety-relevant software do not affect safety-critical functionality by comparing updated system state against the reference. This intermediary mechanism enables updates while maintaining approval integrity.
2Reliability
If software changes are detected in approved safety-critical systems, then system security can be maintained through monitoring, but the system shuts down automatically which reduces productivity
Solution Approach 1:
The patent applies different quality controls to different software components. Safety-critical software components are monitored with strict change detection that triggers shutdowns, while non-safety-relevant components allow updates without triggering system-wide shutdowns. This local differentiation of security policies resolves the contradiction by maintaining security where needed while preserving availability where appropriate.
Solution Approach 2:
The monitoring system is segmented to distinguish between safety-relevant and non-safety-relevant software changes. Only changes in safety-critical components trigger automatic shutdowns, while updates to non-critical components are permitted to proceed. This segmentation allows the system to maintain security monitoring while avoiding unnecessary productivity losses from false positives.
3Reliability
If only approved software is used in safety-critical systems, then system reliability is ensured, but the system cannot be updated with new software which reduces adaptability
Solution Approach 1:
The patent divides software into safety-critical and non-safety-relevant segments. The safety-critical segment must use only approved software to maintain reliability, while the non-safety-relevant segment can be updated with new software including data protection solutions. This segmentation resolves the contradiction by allowing adaptability in non-critical areas while preserving reliability in critical areas.
Solution Approach 2:
The patent creates a dynamic software update mechanism where the system's software composition can change over time. Non-safety-relevant software can be dynamically updated and installed after approval, while safety-critical software maintains its static, approved state. This dynamic approach to software management resolves the contradiction between fixed reliability requirements and flexible update needs.
Data Source
Figure 1
AI summary
The invention relates to a method for operating a safety-critical system, which system comprises at least one first data device (1) having approved, safety-relevant software (2) and at least one reference data device (4) having the same approved, safety-relevant software (2). In the method, after a type check of the system, the at least one first data device (1) is equipped with at least one piece of non-safety-relevant additional software (8, 9, 10) and the at least one reference data device (4) is blocked for software modifications. Before safety-related data information (D) is output, output information (A1, Ar) of the at least one first data device (1) and of the at least one reference data device (4) are checked for accordance with regard to the safety-relevant software (2) by means of a comparison device (7), and the safety-related data information (D) is output in the case of accordance.