A SIS Logic Solver is the decision core of a Safety Instrumented Function (SIF): it validates safety-related inputs, applies deterministic voting/decision rules, and drives a defined safe output action while producing audit-ready evidence (reason codes, timestamps, and state snapshots). It does not measure the physical world and does not provide final power actuation.

• Position in the SIF chain: Sensor → Logic Solver → Final Element. The Logic Solver is where “uncertain inputs” become a “certain decision.”
• Boundary of responsibility: input credibility and consistency are handled here; sensor calibration/physics and actuator sizing are not.
• Auditability requirement: identical validated inputs must yield identical outputs, and each decision must be explainable via a logged cause.

Practical intent: each future chapter (voting, lockstep, isolation, diagnostics, logging) must map back to at least one of these evidence fields.

Voting and redundancy are not “features”—they are responses to explicit assumptions about how channels can fail. Without a written failure assumption set, it is impossible to justify a voting rule, set a detection time budget, or produce audit evidence that a safe state will be reached when needed.

• Random failures: device wear-out, intermittent connections, environmental stress. Mitigation often relies on redundancy, voting, and online detection.
• Systematic failures: design, software, requirements, or configuration errors that can repeat. Mitigation relies on deterministic rules, lockstep/self-check coverage, and controlled change management.

Practical implication: voting primarily counters random faults; lockstep + diagnostics constrain systematic faults by detecting divergence and invalid internal states.

• Fault assumption list: what can fail, how it manifests, and which channel(s) it affects.
• Detection latency: the maximum allowed time to detect each fault type before it can become dangerous.
• Safe state definition: the required output action once a dangerous or unknown state is detected (including latch/reset policy).

• Assumption registry: fault categories with symptoms and affected channels (versioned).
• Latency budget: per fault type, the maximum detection time and the rationale.
• Safe-state contract: output behavior on detection (de-energize/energize-to-trip, latch, reset conditions).
• Fault codes: unique reason codes enabling reconstruction of “what happened” from logs.

Next chapter setup: once assumptions and targets are explicit, voting (1oo2/2oo3), lockstep, isolation, diagnostics, and logging become implementation choices to satisfy the latency and safe-state contract.

Voting only becomes deterministic when each channel’s state has a fixed meaning. This page uses a Trip vote convention: 1 = Trip request (danger detected), 0 = No trip request. Any “invalid/stale” channel must be handled as an explicit state by policy (covered later under diagnostics and logging).

• Nuisance trip sensitivity: 1oo2 trips on any single asserted channel; 2oo3 rejects isolated single-channel assertions unless a second channel corroborates.
• Hazard visibility assumption: if a real hazard can be observed by only one channel (coverage gaps), 1oo2 may trip earlier than 2oo3.
• Timing sensitivity: majority voting can misbehave when channels are asynchronous; validation windows and coherency flags become mandatory controls.

2oo3 and 1oo2 optimize different failure assumptions. 1oo2 prioritizes “trip if any credible channel requests trip,” which can be desirable when hazards may be partially observed. 2oo3 prioritizes “trip on corroborated majority,” which can reduce nuisance trips from single-channel noise or drift. Safety impact depends on the fault model and the coherency controls (thresholds, tolerances, windows).

• vote_mode: 1oo1 / 1oo2 / 2oo3
• input_snapshot: A,B,(C) states captured at decision time
• decision: Trip / Safe
• reason_code: ANY_TRIP / MAJORITY_TRIP / INVALID_INPUT / WINDOW_FAIL
• window_id + timestamp: tie decision to a validation window and time base

Voting rules assume discrete channel states, but real inputs are noisy, delayed, and drifting. Comparator architectures convert ambiguous signals into vote-ready states (0/1/INVALID) under controlled error bounds. The controls are not optional: threshold definition, mismatch tolerance, and debounce/validation windows determine whether voting behaves predictably.

• Analog comparator voting: hardware thresholds with hysteresis and debounce to prevent chatter near trip points; deterministic latency is a key advantage.
• Digital comparator + MCU voting: sampled/filtered signals mapped to states using window rules; enables richer diagnostics and drift-aware policies.
• Window / trend compare (drift-aware): band checks flag out-of-range behavior; trend metrics detect slow bias that can poison long-term voting.

Asynchronous channels can disagree briefly even when all channels are correct. Without a validation window and coherency rules, majority voting can oscillate: early edges create split votes; late edges “correct” them after the decision is already made. This is controlled by windowing (time alignment), debounce, and explicit INVALID handling.

• Noise-induced chatter: signals near threshold flip rapidly; hysteresis and debounce convert chatter into a stable state transition.
• Edge timing bounce: short-lived edges create disagreement across channels; validation windows prevent single-edge artifacts from becoming a vote input.

Requirement: each stability mechanism must be traceable (which threshold/band/window was active during the decision).

A lockstep safety MCU acts like an internal voter: two execution paths run the same instruction stream in tightly aligned cycles, and a cycle-by-cycle compare checks whether computed states remain identical. When a mismatch is detected, the device asserts a fault flag and transitions into a defined safety response (e.g., force safe outputs, latch fault state, and record evidence).

• Core-domain coverage: lockstep is strongest at catching internal random faults that cause divergent computation (register/ALU/control-flow divergence).
• Peripheral-domain boundary: many peripherals are shared. A peripheral fault can feed identical wrong data to both cores, producing consistent but wrong execution that may not trigger a mismatch.
• Practical control: peripheral health flags (timeouts, CRCs, overruns) and input plausibility rules complement lockstep by turning “shared wrong” into an explicit invalid state.

Internal lockstep comparison and external multi-channel voting solve different problems. Lockstep focuses on execution integrity inside the MCU. External 1oo2/2oo3 voting focuses on input-channel consistency and hazard visibility across channels. A robust Logic Solver typically uses both: lockstep to detect internal divergence and external voting/comparison to validate safety inputs.

Lockstep improves fault detection but does not automatically create independence. Shared resources (clock, power, memory paths) can introduce common-cause failures that affect both cores similarly. In addition, a systematic software defect can produce identical wrong behavior in both cores. Therefore, lockstep must be paired with explicit diagnostics, coherency controls, and evidence logging to maintain auditability.

• lockstep_state: enabled / degraded / disabled
• compare_mismatch_flag + fault_reason_code: why divergence was declared
• fault_latch_status: whether the fault is latched and requires a controlled reset
• decision_origin: internal fault vs external vote decision
• software_build_id + config_id: ties behavior to a versioned configuration baseline

Discrete and MCU-based logic solvers can both implement voting, but they differ in diagnosability, timing determinism, audit evidence depth, and lifecycle cost. Selection should be driven by measurable requirements: diagnostic expectations, maximum decision latency, evidence obligations, and change-management maturity.

Reading tip: each dimension should be tied to an explicit requirement. For example, “maximum detection latency” and “minimum evidence fields” determine whether windowing and logging are mandatory.

• Choose discrete-first when deterministic latency and minimal complexity dominate, and evidence needs can be satisfied by external logging.
• Choose MCU-first when richer diagnostics, configurable rules, and audit-grade traces are required, and lifecycle controls (versioning, regression) are feasible.
• Hybrid reality is common: discrete front-end comparators for clean thresholds plus MCU logic for windowing, voting, and evidence logging.

A Logic Solver does not measure the physical world, but it must guarantee that safety inputs remain clean, comparable, and independent. Isolation is not only an electrical barrier: it protects the assumptions behind voting by limiting common-mode coupling, ground shifts, and transient injection that can move multiple channels together and invalidate independence.

• Threshold reference shift: a CM event moves the effective threshold in multiple channels at once, producing “consistent” but wrong vote inputs.
• Transient injection inside the decision window: a spike coincides with validation windows, causing multiple channels to sample the same wrong state.
• Recovery mismatch: isolation elements may saturate or recover at different rates, creating short split votes and oscillating decisions if windowing is weak.

Practical implication: voting assumes independence; CM coupling can collapse independence into a single shared failure mode.

An open failure typically removes a channel and is often detected by timeouts or out-of-range checks. An isolation failure can be more dangerous: signals may still appear plausible while channel independence is degraded. This means “value looks normal” is not sufficient evidence—explicit isolation health and CM event awareness are required.

• channel_health: OK / Degraded / Invalid (per channel)
• isolation_fault_flags: isolation element health and fault latches
• CM_transient_logs: timestamp + severity + affected channels
• coherency_flag: whether inputs were comparable during the decision window

Diagnostics are not “alarms” for operators. The primary safety purpose is to reduce dangerous undetected failures by converting them into detected faults that trigger defined safe actions, degraded modes, or maintenance interventions. Evidence must distinguish detected versus undetected fault classes and show how each is handled.

Diagnostic coverage categories (often described as Low/Medium/High) reflect how much of the relevant dangerous fault space is converted from undetected to detected. The key is not a label: it is a maintained mapping between fault classes and the diagnostics that detect them, plus proof that detection triggers the intended safe response.

Requirement: “undetected” categories must be explicitly listed and mapped to compensating controls (proof-test support, maintenance actions, or design constraints).

• DC% categories: mapped to fault classes and diagnostics (inventory-style)
• detected_fault_list: detected class → diagnostic source → response
• undetected_fault_list: blind-spot class → compensating control
• diag_event_logs: reason_code + timestamp + affected channels

A trip decision is only half of safety. The Logic Solver must enforce a deterministic safe-state policy that defines what outputs do after a detected hazard, how long they persist, and what evidence is required before any recovery. The goal is predictable, repeatable, and auditable behavior under real fault and transient conditions.

Key engineering point: the difference is not “high vs low” but the defined safe direction under loss-of-energy and disturbances.

Safe-state persistence must be explicit. Latched handling keeps the system in safe outputs until reset preconditions are proven. Auto-reset allows recovery when preconditions are satisfied, but requires validation windows to prevent oscillation during noisy boundaries.

• Reset preconditions: channel health is stable, coherency holds, and recent CM transient severity is acceptable for recovery.
• Reset traceability: every reset must be logged with timestamp, actor/mode, and reason.
• Anti-oscillation: recovery windows and throttling prevent rapid trip-reset cycles under marginal conditions.

Safe-state behavior should be modeled as a sequence, not a single output assignment. A robust policy freezes decision context, commits evidence, drives safe outputs, then manages latching and recovery. Determinism ensures the same event leads to the same sequence, while recoverability ensures the system returns only when evidence-based conditions are met.

• safe_state_policy: DE_ENERGIZE / ENERGIZE_TO_TRIP
• latch_state + reset_mode: latched behavior and reset control mode
• reset_preconditions_met: boolean + reason code (why recovery was allowed)
• output_sequence_id + sequence_step: ties behavior to a deterministic output sequence
• reset_event_log: timestamp + mode/actor + reason

Logging is not a “nice to have.” It is the mechanism that turns safety decisions into verifiable evidence. A traceable Logic Solver records a time-ordered sequence of events, vote snapshots, and health context so that post-trip analysis can reconstruct what happened, why it happened, and whether the decision was consistent with the configured rules.

Every trip should bind to a snapshot that captures inputs, voting state, and health context at the decision boundary. Without snapshots, logs show that a trip occurred but cannot prove why it was inevitable under the configured rules.

1. Build the timeline: sort by timestamp and mark key events (CM transient, channel invalid, vote snapshot, trip, safe output sequence, reset attempts).
2. Bind decisions to snapshots: verify that each trip maps to exactly one snapshot and that snapshot fields match the configured vote rules and windows.
3. Explain causality: determine whether the trip was driven by input disagreement, integrity faults, or coherency/CM events; confirm output sequence and latching followed policy.

Result: a defensible evidence chain that supports audits and root-cause analysis without relying on subjective interpretation.

• timestamp + log_sequence: ordered events and missing-entry detection
• event_type + cause_code + affected_channels
• input_snapshot + vote_mode + vote_result + window_id
• channel_health + isolation_fault_flags + lockstep_state
• output_sequence_id + sequence_step + latch_state + reset_event_log

Integration is defined by contracts: what inputs mean, what outputs guarantee, and how diagnostics are acknowledged. This chapter covers interface semantics and evidence fields only; it does not describe PLC/DCS network topologies or plant-wide control architectures.

A voting logic solver depends on inputs that are comparable. A usable input contract defines three layers: value semantics (0/1/INVALID), timing semantics (freshness and maximum age), and quality semantics (OK/DEGRADED/INVALID) that governs how each channel participates in voting.

Practical rule: without a defined INVALID state and freshness rule, voting can mistake “data” for “truth.”

Outputs must be specified as a policy, not a pin toggle: what “Trip” commands (de-energize vs energize-to-trip), whether the state is latched, and what evidence allows recovery. A robust output contract also defines determinism (same cause → same sequence) and verifiability (readback or acknowledgement of output state).

Diagnostics must form a closed loop. A “fault event” becomes actionable only when it is acknowledged and linked to a record ID that supports audits and proof tests. Handshakes should define: fault announcement fields, acknowledgement timing, escalation rules for missing ACK, and proof-test hooks (start/end markers and record IDs).

Example parts frequently used around Logic Solver interfaces (not system networking):

Note: MPNs are examples to anchor integration discussions; final selection depends on isolation rating, channels, data rate, and system constraints.