Trustworthiness Guide - Revision history

Kozsu at 12:21, 3 January 2026

2026-01-03T12:21:27Z

← Older revision		Revision as of 15:21, 3 January 2026
Line 1:		Line 1:
			=== This page is a draft ===
	This page documents the known and potential reliability risks of our solutions and the measures in place to mitigate them. Its purpose is to provide a structured, up-to-date view of factors that may affect system trustworthiness, covering assumptions, limitations, operational risks, and residual risks. The document serves as a living reference to support design decisions, deployments, and continuous improvement in reliability.		This page documents the known and potential reliability risks of our solutions and the measures in place to mitigate them. Its purpose is to provide a structured, up-to-date view of factors that may affect system trustworthiness, covering assumptions, limitations, operational risks, and residual risks. The document serves as a living reference to support design decisions, deployments, and continuous improvement in reliability.

Kozsu: Relay contacts weld or get stuck

2026-01-03T12:10:08Z

Relay contacts weld or get stuck

← Older revision		Revision as of 15:10, 3 January 2026
Line 14:		Line 14:

	With an NC contact, the circuit is closed in its default, unpowered state. The Safety AI must actively energize the relay to change this state. Any interruption—such as cable damage or loss of power—causes the relay to automatically return to its default state, ensuring that a broken connection cannot be interpreted as a valid safe condition.		With an NC contact, the circuit is closed in its default, unpowered state. The Safety AI must actively energize the relay to change this state. Any interruption—such as cable damage or loss of power—causes the relay to automatically return to its default state, ensuring that a broken connection cannot be interpreted as a valid safe condition.

			=== Relay contacts weld or get stuck ===
			Relay contacts may weld or get stuck due to electrical arcing, excessive current, mechanical wear, or contamination. When this occurs, the relay may no longer change state in response to control signals, causing the controller to receive a constant indication regardless of the actual safety condition. This can prevent unsafe situations from being correctly signaled.

			==== Mitigation / solution ====
			Use '''dual-channel relay signaling''' with independent contacts and plausibility checking at the controller.

			By using two separate relay paths driven independently and requiring consistent state changes, welded or stuck contacts can be detected through disagreement or lack of transition. This turns a latent fault into a detectable one.

			Both channels could get stuck if they share a '''common cause''', such as the same relay, the same power supply, identical load stress, or the same environmental conditions. This is why channels must be '''independent''' (separate contacts, relays, wiring, and ideally power) to meaningfully reduce the risk.

Kozsu: Physical connection to the controller breaks

2026-01-03T11:58:18Z

Physical connection to the controller breaks

← Older revision		Revision as of 14:58, 3 January 2026
Line 6:		Line 6:

	== Risks ==		== Risks ==

			=== Physical connection to the controller breaks ===
			The physical connection between the Safety AI and the controller can break due to cable cuts or abrasion, loose or improperly tightened terminals, connector disengagement, vibration, or loss of supply power affecting the relay circuit. If such a break is not explicitly detected, the controller may '''continue to assume that the last received signal remains valid''', potentially allowing operation to continue despite the absence of a reliable safety indication.

			==== Mitigation / solution ====
			Use a '''normally closed (NC) relay contact''' to signal safety status.

			With an NC contact, the circuit is closed in its default, unpowered state. The Safety AI must actively energize the relay to change this state. Any interruption—such as cable damage or loss of power—causes the relay to automatically return to its default state, ensuring that a broken connection cannot be interpreted as a valid safe condition.

Kozsu: Created page with "This page documents the known and potential reliability risks of our solutions and the measures in place to mitigate them. Its purpose is to provide a structured, up-to-date view of factors that may affect system trustworthiness, covering assumptions, limitations, operational risks, and residual risks. The document serves as a living reference to support design decisions, deployments, and continuous improvement in reliability. This page is created in response to our ''S..."

2026-01-03T10:37:48Z

Created page with "This page documents the known and potential reliability risks of our solutions and the measures in place to mitigate them. Its purpose is to provide a structured, up-to-date view of factors that may affect system trustworthiness, covering assumptions, limitations, operational risks, and residual risks. The document serves as a living reference to support design decisions, deployments, and continuous improvement in reliability. This page is created in response to our ''S..."

New page

This page documents the known and potential reliability risks of our solutions and the measures in place to mitigate them. Its purpose is to provide a structured, up-to-date view of factors that may affect system trustworthiness, covering assumptions, limitations, operational risks, and residual risks. The document serves as a living reference to support design decisions, deployments, and continuous improvement in reliability.

This page is created in response to our ''Solutions Roadmap'' published in 2023, where maintaining a documented view of reliability risks was explicitly identified as an action item under the reliability pillar. It fulfills that commitment by formalizing the envisioned “trustworthiness guide” and translating the roadmap intent into a concrete, maintained reference.

The document is structured in a Q&A format, with each entry framed as a ''what-if'' question to systematically explore potential failure modes, edge cases, and misuse scenarios. This approach is intended to make risks explicit, actionable, and easier to review across design, deployment, and operational contexts.

== Risks ==