Track 08 introduced the safety program. This exercise connects that program with documented validation and acceptance. It uses the collective F-signature to identify the safety-related project state, an acceptance test to check the required safety responses, and a signed protocol to record the results. A change to F-logic requires an impact assessment and validation of the affected functions before the changed application is accepted.
F-block signatures identify block states, while the collective F-signature identifies the safety-related project state. Compare it in Safety Administration with the value recorded in the acceptance documents: matching signatures support the comparison with the accepted version. A match alone does not validate the machine. Edit the blocks in this simulation to see which edits change its displayed signature.
In this simulation, editing the standard blocks leaves the displayed F-signature unchanged. Editing a safety block changes it and marks the record as needing review. On a real machine, an unchanged F-signature is not permission to ignore the safety impact of a standard-program change. Compare the changed project with the accepted reference, determine which safety functions are affected, and document the validation and acceptance required for those changes.
Certified components do not validate your application as installed. Use a planned acceptance procedure derived from the safety requirements and risk assessment, with controlled test conditions, measured responses and recorded results. The following sequence is a teaching example, not a complete machine acceptance procedure or permission to introduce live faults without the approved safeguards. Run the simulated protocol:
🔐 Safety Administration editor. Use it to compare offline and online F-signatures, examine F-runtime group status and check access protection and change information. Include those checks in the acceptance record and compare the relevant state before and after downloading. The editor supports the investigation; its display does not replace the required function tests.
🚫 Use the approved safety test procedure. Do not treat forcing or manipulating a sensor as a shortcut around the safety function. Test and commissioning facilities depend on the F-system, its operating mode and the device. Use only the facilities and safeguards specified for that system in the approved procedure, and record any temporary intervention and its removal before returning the machine to service.
📝 Assess changes before choosing the retests. A documented impact analysis determines which functions need validation again. A like-for-like F-module replacement and an F-logic change do not automatically require the same tests. Check the affected addressing, configuration and function, compare the relevant signatures and update the acceptance record. The analysis must also consider effects on safety-related data that was not edited.
👤 Record who performed and accepted the tests. The acceptance record must identify the competent people responsible for the work and the results they accepted. Apply the project's required independence and approval arrangements. A signature records that responsibility; it does not replace evidence that the installed safety functions passed the tests specified for the application.
A technician adjusts a delay inside FB_GuardDoor (an F-block) to suppress a nuisance trip, downloads it and resumes production. The machine appears to run normally. What must happen before the changed safety application can be accepted?