HIMA Safety PLC Spares and SIL-Rated Replacement

A HIMA safety controller is not a PLC that happens to be painted differently. It is a certified element of a safety instrumented system, and replacing a module in one carries obligations that replacing a standard automation module does not. Buyers routinely send us a HIMA module part number and expect the transaction to work like an I/O card order. It can, but only if the specification, the certification evidence and the post-installation proof test are handled properly. This guide explains what the families are, what interchangeability actually means in a SIL context, and what a competent replacement process looks like.

The families

The H41q and H51q differ principally in rack format and I/O capacity rather than in safety concept. Both implement a redundant architecture designed to achieve high safety integrity while tolerating single faults - which is precisely why module substitution is constrained.

What SIL certification means for a spare part

A safety instrumented function is assigned a Safety Integrity Level based on the risk reduction it must deliver. That SIL claim rests on a calculation that uses documented failure-rate data for every element in the loop - sensor, logic solver, final element. The logic solver's contribution depends on the specific certified module types, the redundancy configuration, and the proof-test interval.

Three consequences follow, and they are the reason a HIMA order is not an ordinary order:

1. 01The replacement module must be a certified type covered by the system's safety manual. A module that is functionally similar but not the certified variant invalidates the SIL calculation for every function that passes through it.
2. 02The safety configuration - the application program, the redundancy settings, the diagnostic parameters - must be restored and verified, not just loaded. Verification means demonstrating the safety function operates as designed, and recording that.
3. 03A proof test of the affected safety functions must be executed and documented after replacement. In most regulatory regimes and under IEC 61511 practice, an undocumented change to a safety instrumented system is a compliance finding independent of whether the system works.

Identifying the module

HIMA modules carry a type designation and an article number on the front plate or side label - forms such as F 8621A, F 3236, F 6217, F 7126 across processor, I/O, communication and power supply classes. Record the full designation including any revision or index characters, and the serial number. Photograph the label; do not transcribe it.

Also record the rack position and the surrounding module complement. Redundant architectures place constraints on which slots accept which module types, and a module that is correct in isolation can be wrong for the slot.

Firmware, operating system and tool versions

Safety controllers are more sensitive to version alignment than standard automation platforms, because the certification applies to specific combinations.

• Module firmware must be a version compatible with the running system and covered by the certification.
• The engineering tool version (ELOP II for the classic quad platform, SILworX for the newer generations) must match the project. Opening a project with a mismatched tool version can be blocked outright.
• The safety manual for the system version defines the permitted configurations. It is the governing document, not the marketing datasheet.

Migration from the classic platform

The H41q/H51q installed base is large and long-lived, and the platform has a defined successor. Migration is a project rather than a swap: new hardware, application program conversion, re-verification of every safety function, updated safety requirement specification, and a full validation before the system is returned to service. It also usually requires a shutdown of the protected process.

The realistic planning horizon is measured in quarters, not weeks, and the cost driver is engineering and validation rather than hardware. Plants that treat safety-system obsolescence as an IT-style refresh underestimate it by a wide margin. The counterpoint is that running a safety system past the point where certified spares are obtainable is not a defensible position in front of a regulator or an insurer.

Spares holding for safety systems

Because the consequence of an unavailable spare is either a process shutdown or continued operation with a degraded safety function, safety-system spares holdings are typically deeper than automation holdings.

• Hold at least one of each I/O module type in service, and more where a type is heavily used.
• Hold power supply modules - the same thermal ageing that affects turbine control affects safety racks.
• Hold processor and communication modules where the architecture does not already provide sufficient redundancy to run to the next planned outage.
• Store modules in antistatic packaging in a controlled environment, and record their firmware revision on the packaging so the version question is answered before the module is opened.
• Review the holding whenever the system firmware is updated, because compatibility may have moved.

What to send with a HIMA enquiry

1. 01Full module type designation and article number, photographed from the label, plus serial number.
2. 02System family and the rack configuration, with the module's slot position.
3. 03System firmware and engineering tool version.
4. 04The SIL assigned to the functions passing through the module.
5. 05Whether the system is currently running degraded, which determines urgency.
6. 06Whether you require certification documentation supplied with the module - you should.
7. 07Destination airport, and any import conformity requirement in the destination country.

On genuine supply for safety hardware

There is no acceptable version of a grey-market safety module. A module without traceable provenance cannot be shown to be the certified type at the certified revision, which means the SIL claim for every function through it cannot be substantiated. We supply new and genuine OEM equipment only, with manufacturer documentation and serial-number traceability, and for safety-system hardware we will decline an order we cannot fill that way rather than offer an alternative channel.

Proof testing: what it is and why the interval matters

A safety instrumented function's SIL claim depends on a proof test performed at a defined interval. The proof test reveals dangerous undetected failures - the failures that diagnostics do not catch and that would otherwise remain hidden until a demand occurred. Lengthening the interval raises the probability of failure on demand and can drop a function below its required SIL.

• The interval is an input to the SIL calculation, not an operational convenience. Changing it changes the calculated performance.
• Proof test coverage matters as much as frequency. A test that exercises only part of the function leaves the rest untested regardless of how often it is run.
• The test must exercise the full loop where practicable - sensor through logic solver to final element - not just the logic solver.
• Results must be recorded, including any failures found, because failure data feeds back into the reliability model.
• Partial stroke testing on valves supplements but does not replace full proof testing.

When a module is replaced, the affected functions require a proof test before the system is relied upon again. This is not optional and it is not satisfied by the module powering up without a fault.

Bypasses, overrides and operating with a degraded system

A failed module in a redundant architecture may leave the system operating with reduced fault tolerance rather than failed outright. This is a defined and manageable state, but it is time-limited and it must be managed explicitly.

1. 01Establish what the architecture degrades to. A system designed for single-fault tolerance operating with one fault present has none remaining.
2. 02The safety manual usually states a maximum repair time - the period the system may operate degraded before the risk reduction claim no longer holds.
3. 03Record the degraded state formally, with compensating measures - increased operator vigilance, manual monitoring, or reduced operating envelope.
4. 04Bypasses applied to permit operation must be registered, time-limited, authorised at the appropriate level, and physically visible so they cannot be forgotten.
5. 05Track the repair clock. Operating past the stated repair time without reassessment is a documented breach of the safety case.

Cyber security and network separation

Modern safety controllers carry Ethernet interfaces, and the separation between the safety system, the basic process control system and the wider network is part of the safety case. When replacing a communication module or upgrading firmware, confirm that the network segregation and any security configuration are restored as designed. A safety system reachable from a business network is a hazard independent of its functional performance, and it is one that has been exploited.

Documentation the plant needs, and when to ask for it

Safety-system procurement generates a documentation set that has to survive audit years later. Ask for it with the order rather than after delivery, because retrieving it retrospectively is significantly harder.

1. 01Certificate of conformance naming manufacturer, module type, article number and revision.
2. 02Serial numbers recorded against the delivered items.
3. 03The functional safety certificate for the module type, and the applicable safety manual reference.
4. 04Firmware revision as delivered, recorded in writing rather than only on the device.
5. 05Declaration that the item is new and genuine, with a statement of supply chain.
6. 06Any manufacturer notices affecting the module type - errata, application notes, or lifecycle announcements.

How we handle safety-system enquiries

We supply safety controller hardware new and genuine only, with certification documentation and serial traceability, and we decline rather than substitute. This is not a commercial posture, it is the only defensible one: a module whose provenance cannot be evidenced cannot be shown to be the certified type at the certified revision, and every safety instrumented function passing through it then rests on an assumption rather than a demonstration. Where a module is genuinely unobtainable, the honest answer is a migration plan, and we would rather give that answer than an order confirmation.

Common misconceptions

• That a safety controller is a redundant PLC. It is a certified element whose failure-rate data underpins a quantified risk-reduction claim; redundancy is one mechanism, not the point.
• That a module powering up without a fault proves the safety function works. It proves the module is alive. The function requires a proof test.
• That a functionally identical module from the same family is an acceptable substitute. Only the certified type at a covered revision is, and the safety manual governs.
• That the safety system can be left degraded until the next outage. The safety manual usually states a maximum repair time, and exceeding it invalidates the claim.
• That a firmware update is routine maintenance. On a safety system it is a change requiring impact assessment, re-verification and documentation.