Why Not Every PLC I/O Point Serves the Same Purpose
A basic I/O sizing exercise treats every digital and analog point similarly — count the points, determine module density, calculate chassis and power requirements. But for a process with functional safety requirements, a genuinely important architectural distinction applies: I/O points serving safety instrumented functions (SIF) generally cannot simply be added to the same standard PLC I/O sizing pool as basic process control I/O, because functional safety standards require dedicated, certified safety-rated hardware for these specific points.
The Distinction Between BPCS and SIS
The Basic Process Control System (BPCS) is the standard control system responsible for normal, non-safety process control and monitoring — the kind of I/O sizing this site's PLC I/O Sizing Tool addresses directly. The Safety Instrumented System (SIS) is a functionally and often physically separate system specifically responsible for safety instrumented functions — automated actions that prevent or mitigate a hazardous event, such as an emergency shutdown system. Industry functional safety standards (IEC 61511 for the process industry, IEC 62061 for machinery applications) require this separation as a fundamental architectural principle, not an optional design preference.
Why SIL-Rated Hardware Is Required for Safety I/O
Safety Integrity Level (SIL) ratings quantify how reliably a safety function performs its intended protective action when called upon — SIL-rated PLC hardware (a dedicated safety PLC platform, distinct from a standard process control PLC) has been specifically designed, tested, and certified to meet defined reliability and fault-tolerance requirements appropriate to a given SIL rating, incorporating features like internal diagnostic coverage, redundant processing paths, and certified failure-mode behavior that standard, non-safety-rated PLC hardware is not designed or certified to provide.
Why Standard PLC I/O Cannot Simply Be Repurposed for Safety Functions
It might seem straightforward to designate a subset of otherwise-standard I/O points as "safety" points within the same standard PLC and I/O architecture used for basic process control — but this approach does not satisfy functional safety requirements, since standard PLC hardware and I/O modules have not been certified to the specific reliability, diagnostic coverage, and fault-tolerance requirements a genuine SIL-rated safety function requires. Achieving a certified SIL rating for a safety function requires using genuinely certified safety PLC hardware and I/O, not simply treating standard hardware as if it were safety-rated by policy or intention alone.
Why This Means Two Separate I/O Sizing Exercises for Safety-Relevant Projects
For a project with functional safety requirements, I/O sizing genuinely needs to be performed twice — once for the standard BPCS I/O using tools and methods like this site's PLC I/O Sizing Tool, and separately for the SIS safety I/O using the specific certified safety PLC platform's own sizing methodology and module offerings, which are a distinct product line from the same or different manufacturers, not simply a different configuration option within the standard platform's product catalog.
Why SIL 2 and Above Commonly Requires Redundant Controllers
Beyond the basic BPCS/SIS separation, higher SIL ratings (commonly SIL 2 and above, per standard practice referenced in industrial control system design) typically require redundant safety controller architecture — a second, redundant CPU providing automatic failover in the event of a primary CPU or power supply fault, since a single-controller architecture, however reliable individually, cannot achieve the reliability levels required for higher SIL ratings without this redundancy. This is a distinctly different consideration from the local-versus-remote I/O architecture decision or basic expansion chassis addition covered elsewhere in this cluster — redundant controllers specifically address fault tolerance and reliability for safety-critical functions, not simply I/O capacity expansion.
Why Determining Safety Requirements Should Happen Before I/O Sizing, Not After
Because safety I/O and standard I/O require fundamentally different hardware platforms and sizing approaches, determining which specific I/O points on a given project actually serve safety instrumented functions — typically established through a formal process hazard analysis and safety instrumented function determination process — needs to happen early, before finalizing I/O architecture and procurement, rather than being addressed as an afterthought once standard I/O sizing is already complete. Discovering safety requirements late in a project risks requiring significant rework of an I/O architecture that was designed without safety separation in mind from the start.