Functional Safety Electronics

It means every credible fault drives the system into a predefined safe state, through a path that does not depend on the part that failed. That covers loss of power, a communication timeout, two sensors that disagree and a hung processor. We define the safe state for each hazard up front (usually de-energized, sometimes a controlled stop or a held position). Then we design hardware, firmware and software to reach it within a fault-reaction time we measure on the bench.

Certification is issued by accredited third parties such as TÜV, UL or exida, and no design house can self-certify. We engineer to the standard from day one and produce the work products the assessor reviews: safety plan inputs, safety requirements, architecture rationale, FMEDA inputs, traceability matrices and test reports. Then we support you through the assessment and any findings.

Often, yes. We start with a gap assessment against your target standard. Then we propose the smallest set of changes that closes the gaps, such as an independent supervisor MCU, an added hardware trip path, electronic circuit breakers in place of mechanical ones, watchdog and self-test firmware, or protected messaging on an existing bus.

Redundancy (two identical channels) covers random hardware failures. Diversity also protects against common-cause and systematic faults that would take out identical channels together. It means different sensing principles, different processors, or a hardware comparator alongside firmware. The right mix follows from your SIL or PL target, the diagnostic coverage required and cost. A common pattern is a cross-monitored 1oo2 architecture plus an independent hardware shutdown path.

It is a hardware route (a comparator, discrete logic or a separately supervised controller) that can remove energy from the hazard even if the main processor is frozen. For example, it can open a contactor, disable a gate driver or drop a spring-applied brake. Because it shares no firmware with the main controller, a single software defect cannot prevent the safe state.

We supervise every rail for under- and over-voltage, add hold-up energy so firmware can log the event and park safely, and protect inputs against reverse polarity, surge and transients. For redundant supplies we use ideal-diode ORing, the approach built into the INTERCAL8 ICL8-PC548. For distribution we use electronic circuit breakers with programmable trip limits instead of fuses that must be replaced.

Yes. In a safety product, immunity is a safety requirement. We design for EMC from the schematic and PCB stack-up onward and run pre-compliance testing during development. We also confirm the system fails safe rather than misbehaving under ESD, EFT and surge, all before you book an accredited lab.

Discipline and evidence. We write to MISRA C, run static analysis on every build, avoid dynamic memory after initialization, partition with the MPU, monitor program flow, use windowed watchdogs, and run start-up and periodic RAM, flash and CPU self-tests in the style of IEC 60730 Class B. Critical variables are stored redundantly and checked before use, and every requirement traces to a test.

When the integrity target calls for them. Options include lockstep-core MCUs with ECC memory and vendor safety manuals, and pre-certified RTOS kernels. A simple, fully analyzable bare-metal scheduler is sometimes easier to justify. We choose based on your SIL, PL or ASIL target, cost and the evidence the assessor will want.

We use the black-channel principle. Every safety-relevant message carries a CRC, a sequence counter and a freshness deadline. The receiver drives its safe state on corrupted, repeated, out-of-order or stale data. That lets the transport (CAN, CAN FD, RS-485 or even a wireless link) stay a standard bus with no safety rating of its own.

Images are signed and verified before boot, stored in A/B partitions with automatic rollback, and only applied when the system is in a safe state. Safety parameters are CRC-protected and version-locked to the firmware, and every update is logged.

Typically a commissioning and configuration tool with protected safety parameters, an operator HMI, time-stamped fault and event logs, and a diagnostics dashboard, either on-premises or in the cloud. We integrate with SCADA and plant systems over MODBUS, OPC UA or MQTT.

We trace every hazard to a requirement, a design element and a test. Then we run tests that try to break the design: hardware-in-the-loop rigs, unplugged and shorted sensors, corrupted and delayed messages, browned-out supplies and deliberately hung processors. We measure each fault-reaction time and record it as evidence.

In monitoring and maintenance, not in the safety function itself. The safety function stays deterministic, analyzable and verifiable. AI watches the trends around it (current signatures, temperatures, vibration and trip history) to predict failures, flag drifting sensors and schedule maintenance. It can request a safe action, but it can never block one.

Yes. Models learn what normal inrush, start-up and load profiles look like, classify why each trip happened, and recommend threshold changes within validated limits. The hard protection limits stay fixed in hardware and firmware, and AI improves availability around them.

A natural-language interface to INTERCAL8 power-control hardware. Operators can ask for status, balance a system or set rules without writing code, for example to shed non-critical loads when consumption crosses a threshold. In safety-related designs we limit the assistant to non-safety functions.

LOMA electronic circuit breakers give you fast programmable protection, remote reset and rich per-channel diagnostics, all valuable in a failsafe design. Whether a given LOMA product can carry a safety function on its own depends on the rating your application needs. Where a SIL- or PL-rated function is required, we pair LOMA with a dedicated safety channel. Contact us for current product documentation.

Through standard industrial protocols (MODBUS, J1939 and CANopen) or INTERCAL8’s proprietary Wireless CAN. Rule-based control can come from SCADA, the ICL8-EB104 panel controller or an edge-AI controller.

Send us a message through our contact form with what you’re building, where it will operate and your timeline. We’ll schedule a technical discovery call, then send a scoped, phased proposal, so you can begin with an architecture study or prototype and commit to production later.

Yes. We can own the whole system as a Team-in-a-Box, or take a defined piece (the power stage, the firmware, the cloud pipeline, the AI model) and work inside your repositories, toolchains and design reviews.

Yes. We carry designs from prototype through DFM and DFT reviews, test-fixture and end-of-line test development, pilot builds and full-scale production support.