compare · South Africa
Safety PLC vs Non-Safety PLC: Architecture and Training
Compare safety PLC vs non-safety PLC architectures, stop categories, evidence and lifecycle effort, with South African course and vendor review questions.
The safety PLC vs non-safety decision starts with the functions an installation must perform and the evidence required for them. A standard PLC can handle ordinary sequencing while a separate safety-related system handles protective functions. A suitable integrated controller may support both standard and safety application areas. A safety PLC is therefore one possible architecture, not the automatic answer to every protective-control requirement.
For a South African learner, the useful comparison is about boundaries, supported capabilities, validation and maintenance. It is not a universal price multiplier or a claim that every mine needs the same SIL. This guide includes fictional architecture and procurement worksheets. They help you organise questions for a specialist; they do not select or approve equipment for a real machine.
Compare the function first, then the controller
Start by listing each required function in plain language. Record its initiating condition, required result, operating modes, response requirements and evidence owner. Keep production objectives and protective requirements identifiable even when they eventually share a cabinet or engineering environment.
“Count completed cartons” and “prevent access to a hazardous movement under defined conditions” are different requirements. However, a name such as alarm, interlock or process control does not determine its safety significance on its own. That depends on the role the function plays in the assessed application. Avoid declaring whole software categories permanently outside safety considerations.
The safety PLC introduction explains function boundaries, response budgets and reset behaviour. Use it to establish the terminology before comparing platforms. The current page addresses a different question: what evidence would make two proposed architectures meaningfully comparable?
Four architectures worth distinguishing
| Proposed arrangement | What to investigate | What its name does not establish |
|---|---|---|
| Standard PLC for ordinary control, separate safety relay system | Suitability of the relay system and complete protective path | That ordinary PLC logic performs the protective function |
| Standard PLC plus configurable safety controller | Configuration capability, interfaces and application validation | That all devices sold as relays are fixed-function only |
| Integrated controller with standard and safety application areas | Supported separation, permitted data exchange and configuration | That every routine and I/O point has safety integrity |
| Dedicated safety control system beside ordinary process control | Required independence, interfaces and lifecycle responsibilities | That physical separation alone proves all requirements |
These are discussion categories rather than interchangeable construction options. A qualified assessment may exclude an arrangement for a particular application. Conversely, a safety-related requirement does not automatically exclude relay-based or other suitable technology merely because it does not carry the label PLC.
Rockwell's 440C-CR30 product documentation provides a concrete example of a software-configurable safety relay using safety function blocks. Its stated capabilities are subject to the product's application conditions. This is enough to reject the simplistic claim that every safety relay is non-programmable or that only a PLC can be considered for a defined safety function.
Certification, capability and achieved integrity are separate
A product certificate has a scope: a particular product or family, versions, standards, restrictions and conditions. Obtain the relevant certificate and safety manual for the actual proposed equipment. A distributor's sentence saying “up to SIL 3” is not a complete application assessment.
The required integrity comes from the applicable risk-assessment and allocation process. The achieved result depends on the implemented function and its supporting evidence. Do not place the requirement only on the CPU and ignore sensors, communications, outputs, final elements or the conditions needed for them to work.
For machinery, ISO 13849-1:2023 addresses safety-related parts of control systems, including software and multiple technologies. Its public scope does not prescribe the safety functions or required Performance Levels for individual applications. Ask which application-specific requirements and assessment method the project uses rather than assigning a target from a sector label.
Ask precise questions about diagnostics
A comparison should name the relevant fault behaviour and the product configuration. “Safety I/O detects faults” is too broad to tell you whether a proposed sensor, connection and monitoring arrangement meet the particular requirements. Ask where the relevant behaviour is documented and how it will be verified.
Do not apply a diagnostic-coverage percentage from one module to every module on the same network. Nor does adding a second Boolean input to an ordinary program establish an assessed two-channel safety architecture. A normal functional test and a fault-oriented assessment ask different questions, and both need clearly stated limits.
For introductory learning, PLC troubleshooting workflows help distinguish input observations, program decisions and physical outcomes. Carry that discipline into the comparison: write what each test actually demonstrates instead of extending one observation into a whole-system claim.
Stop category, architecture category and reset are different questions
The word category appears in more than one safety context. Always include the relevant standard and meaning. A stop category describes stopping behaviour; an architecture category under ISO 13849 is a different concept. Neither is simply another spelling of a SIL number or a reset option.
Schneider Electric's explanation of stop categories distinguishes the following behaviours under EN 60204-1: category 0 removes actuator power immediately; category 1 uses power for a controlled stop and removes it after stopping; category 2 uses a controlled stop with power remaining available. These descriptions do not specify whether an operator presses a reset button.
Do not read that list as permission to select any category for any protective function. The required behaviour belongs to the application's assessment and relevant requirements. In particular, removing power is not a universal substitute for determining the required safe condition and controlling the associated hazards.
Why a reset latch cannot define stop category
Imagine two fictional course descriptions. Course A says its example removes actuator power immediately and requires a subsequent intentional reset. Course B says its example completes a powered controlled stop, then removes power, and also requires intentional reset. Their shared reset requirement does not make their stopping behaviours identical.
Likewise, describing a program as manually reset does not establish category 1 stopping. You still need the actual stopping sequence. A requirements worksheet should therefore have separate fields for stopping behaviour, reset conditions and restart conditions. Missing information in one field cannot be filled by copying a value from another.
The Pilz emergency-stop reset explanation says that resetting an operated emergency-stop device must prepare for restart without automatically restarting the machine. Use that distinction when reading a course demonstration. The particular device's instructions still determine how its reset is implemented and monitored.
Worked architecture worksheet: trace every requirement to evidence
Consider a fictional training brief for comparing proposals Alpha and Beta. The exercise supplies six requirements, labelled R1 through R6. These are invented document-review requirements, not a risk assessment or a complete safety specification. No real equipment is selected by this example.
R1 asks for the intended protective-function boundary. R2 asks for evidence supporting the required response. R3 asks for the stated reset and restart behaviour. R4 asks for documented standard/safety data exchange. R5 asks for the applicable component conditions of use. R6 asks for the validation and maintenance responsibilities.
For each requirement, mark evidence as Accepted, Open or Rejected. In this worksheet, Accepted means that the named course reviewer has accepted the submitted evidence against the fictional brief. Open means evidence is missing or unresolved. Rejected means the submitted material conflicts with the brief. These labels are review statuses, not safety certification results.
| Requirement | Alpha status | Beta status |
|---|---|---|
| R1: function boundary | Accepted | Accepted |
| R2: response evidence | Accepted | Accepted |
| R3: reset and restart | Accepted | Accepted |
| R4: interface evidence | Open | Accepted |
| R5: conditions of use | Accepted | Accepted |
| R6: responsibilities | Accepted | Accepted |
Alpha has five accepted items out of six, about 83.3%. Beta has six out of six. Under the worksheet rule, a proposal is ready for the next review stage only when every requirement is Accepted. Alpha therefore remains open. Reporting an average of 83.3% as “sufficiently safe” would change the rule and misrepresent the evidence.
Now give Beta a revised R2 document that conflicts with the specified response. Its status becomes Rejected, and Beta no longer meets the gate even though five other items remain Accepted. A good-looking total cannot cancel a failure against a mandatory requirement.
Add revisions instead of silently replacing history
Give every evidence item an identifier, revision, reviewer and decision date. If Alpha submits a revised interface description, record what changed and why R4 can be reconsidered. Preserve the earlier open finding. Otherwise, a later reader cannot distinguish evidence that was present initially from evidence supplied after a review.
Add a seventh requirement, R7, for an unresolved maintenance-access condition. Both proposals now have an Open item until it is addressed. A previously complete six-item record is not automatically complete against a seven-item brief. This is a practical example of why configuration and requirement changes must update the review scope.
The rule can be tested without hardware: enumerate all three statuses across six requirements. There are 3 raised to the sixth power, or 729 combinations. Exactly one combination passes the all-Accepted gate. This tests the worksheet's decision logic; it says nothing about whether an Accepted engineering document is substantively correct.
For learners building ordinary software tests, use PLC program testing resources. Keep the distinction between checking a decision rule and validating the evidence supplied to that rule.
Compare lifecycle effort without inventing a price crossover
A hardware quote is only one part of comparing proposals. Ask what each offer includes for engineering software, configuration, documentation, application verification, commissioning support, training, spares and later modifications. Keep common items separate from differences so the comparison does not count the same work twice.
Use a fictional effort worksheet with arbitrary study units, not rand or working hours. Alpha has 18 units for initial configuration, 12 for documentation and 10 for review, giving 40 initial units. Beta has 26, 10 and 8 respectively, giving 44 initial units. These numbers are invented to practise arithmetic and sensitivity analysis, not estimates of vendor performance.
Suppose each future change event adds six study units for Alpha and two for Beta, with the same event scope assumed for both. For n events, Alpha totals 40 + 6n and Beta totals 44 + 2n. At zero events Alpha is lower, at one event both total 46, and at two events Alpha totals 52 while Beta totals 48.
The equality at one event follows from those supplied assumptions alone. It is not evidence that a configurable safety relay becomes uneconomic after one change, or that a safety PLC is always easier to maintain. Change the assumptions and the comparison changes. If Beta instead needs six units per event, its initial four-unit difference remains for every event count in this simplified model.
Establish eligibility before comparing totals
Apply the evidence gate before using an effort score to rank proposals. An incomplete proposal cannot become eligible merely by offering fewer study units or a lower price. Once proposals meet the same brief, a comparison can examine their documented differences and uncertainty.
Also check whether the event scopes match. “Change one label” and “add a protected zone” are not interchangeable units of work. A proposal that excludes validation effort cannot be directly compared with one that includes it unless the missing scope is made explicit. Ask for written inclusions, exclusions and dependencies before drawing a conclusion.
For actual South African purchasing, obtain current quotations for the exact bill of materials and required services. Confirm currency, tax treatment, delivery, software access and support terms with suppliers. This article provides no local list-price multiplier, savings promise or universal number of safety functions at which one architecture becomes cheaper.
Standard and safety logic can coexist with defined boundaries
An integrated platform may provide distinct standard and safety application areas. Their presence in the same controller does not mean ordinary data becomes safety data, or that every instruction has the same permitted use. Read the exact platform's rules instead of transferring assumptions from another product family.
Rockwell's GuardLogix standard-tag mapping documentation distinguishes standard tasks reading safety tags from mapping standard data into safety tags. It warns that mapped standard data remains standard data and needs appropriate treatment. A copy operation does not confer safety integrity.
A practical comparison should therefore request an interface schedule. For every exchanged item, list its source, destination, meaning, update behaviour, validity handling and intended influence. Distinguish status used for a display from information that affects a protective decision. Naming a tag SafePermit does not establish the properties of its source.
For ordinary control foundations, study PLC language selection criteria. Language availability depends on the platform, routine type and software configuration. Avoid comparing all safety PLCs against an imaginary standard PLC that supports every language without restriction.
South African training and procurement questions
A useful course should say whether it teaches general concepts, a specific vendor environment, application design or specialist functional-safety assessment. Ask for prerequisites, equipment access and assessed deliverables. A learner who needs basic I/O interpretation has a different starting point from an engineer reviewing a safety requirements specification.
If you search for safety PLC training in Johannesburg, Pretoria, Durban, Cape Town or Gqeberha, verify the actual delivery location and practical facilities. A national advertising page does not prove that each city has a training rig. For online courses, ask which exercises run in software and which require supervised hardware or a later workplace assessment.
For a mining, manufacturing or process-industry brief, request the actual project requirements and applicable standards from the responsible organisation. Do not substitute claims that every South African mine requires SIL 2 or every petrochemical function requires SIL 3. Sector names alone do not provide a complete function specification or prove the applicable legal obligations.
Ask who issues any qualification or competence certificate, what is assessed and how claims can be verified. Vendor course completion, attendance and specialist certification are different outcomes. A broad industrial automation course comparison can help you place safety-specific learning within a wider training plan.
For supporting circuit study, the PLC wiring lesson catalogue provides a relevant next step. It should be treated as educational practice, not a native certified safety-controller environment or a service that approves an installed protective system.
Questions about safety PLCs versus standard PLCs
Does a safety requirement always mean buying a safety PLC?
No. The suitable implementation follows the application's requirements and assessment. A safety relay, configurable controller, safety PLC or another appropriate architecture may be considered within its conditions of use. The equipment label alone cannot establish suitability. Ask for the evidence supporting the proposed complete function.
Can a standard PLC display safety status?
It can be part of a documented status-display arrangement where the selected platform permits it. That is a different role from directly controlling a protective function using unqualified standard data. Check the direction of information flow, permitted access and the consequences of stale or incorrect information.
Is a manual reset the same as stop category 1?
No. Reset describes preparation for a subsequent action under specified conditions. Stop category 1 describes powered controlled stopping followed by removal of actuator power. Keep the two fields separate in a course worksheet or specification, and verify the behaviour required by the particular application.
How much more does a safety PLC cost in South Africa?
There is no defensible universal multiplier in this guide. Request comparable, current offers with the exact hardware, software and engineering scope. The fictional study-unit example shows how a conclusion can change with future work assumptions; it is not a quotation or a prediction of local installation costs.
Can I compare both architectures in a browser simulator?
You can compare defined software models and record their assumptions. Do not describe a conceptual model as a certified hardware implementation or infer real fault coverage from it. For this page, the document-status gate and effort worksheet are transparent learning exercises whose results can be checked independently of a safety runtime.
What should a strong learner portfolio contain?
Include a function-boundary sketch, an evidence register, a terminology comparison and a clearly labelled worked example. Record sources, revisions, unresolved questions and the limits of each result. A portfolio that distinguishes what has been demonstrated from what still requires assessment gives an instructor useful evidence of your reasoning.