You must have clear delineation between safety and non-safety functions.
Take the example of tank with an agitator in it. The tank may have an emergency stop next to it, and a guard switch on the lid. Either of those must stop the agitator. The agitator has a standard motor contactor to start and stop it, and the power supply to that contactor comes via a pair of safety contactors.
The monitoring of the emergency stop and guard switch must be done exclusively by the safety code.
The energisation and de-energisation of the safety contactors, when emergency stop or guard switch are activated, must be done exclusively by the safety code.
The monitoring of those safety contactors to ensure they are operating correctly must be done exclusively by the safety code.
The energisation and de-energisation of the agitator's standard contactor would be done by the standard code. It does, of course, make sense that the standard code would check the status of the safety systems before turning on its output. For one thing, it's just standard good practice to make sure that you don't try and start a motor until all the preconditions for it being able to run are met. For another, many standards require that a reset of the safety systems do not permit an automatic restart of machinery, so it makes sense for the standard code to monitor the safety system and ensure it doesn't try to start until the safety systems are healthy and then subsequently a new start command is received. And thirdly, energising your standard contactor won't do a thing if your upstream safety contactors are de-energised.
The old way of doing this was to have a standalone, hardwired safety relay handling all of the safety "code", and then it would send a digital input to the PLC as a "status" feedback. That digital input would be used in the control logic for all devices. Using that method, you have very clear delineation of safety vs non-safety - there are separate physical devices. The hardwired safety circuits manage safety, and the PLC (and it's ladder logic) manage non-safety, with a simple status interface between to allow the PLC to make informed "decisions" about whether motors are ready to be started or not. But even if the PLC makes an "incorrect" decision about whether a motor can be safely started, the hardwired safety system will enforce the safety requirements with no ability for the PLC to override them (i.e. because the upstream safety contactors will cut power to the agitator even if the standard contactor is incorrectly energised).
Now with safety PLC's becoming more common, it tends to look slightly different - there's a safety task, which handles all of the safety functions, and it passes the status to the non-safety code via an internal tag rather than a digital input. But exactly the same thing applies - the safety task manages safety, and the standard tasks manage non-safety, with a simple status interface between to allow the PLC to make informed "decisions" about whether motors are ready to be started or not. But even if the non-safety task makes an "incorrect" decision about whether a motor can be safely started, the safety task will enforce the safety requirements with no ability for the non-safety task to override them (i.e. because the upstream safety contactors will cut power to the agitator even if the standard contactor is incorrectly energised).
In practice, the way this second approach looks is very much as it appears in your screenshot above. As long as the safety task is doing its thing independently, it's totally fine for the non-safety task to receive information from the safety task about the current safety status, to assist it with making non-safety, functional decisions about the state of the machine.
