I like to think about an input signal in the four steps autlined above:
1 – Signal is collected (or received) in raw format. typically sampled on a digital or adc pin in raw format. A 12 bit ADC will have a raw value between 0 to 0xFFFF.
2 – A raw value is of little use, so we usually normalize this in several steps. A raw ADC sample is usually converted to Volt because that is the actual value on the ADC pin. A 3.3V system will precent a value between 0 to 3.3V. But, even this is a de-normalized value that reprecent something else – and assuming this is Temperature you need to scale this to the actual range ending up with a normalized value in Celcius ( as an example).
3 – Processing receives a normalized Temperature and will use that for precentation and input to sub-processing. Maybe this signal is needed together with others or you just monitor and raise temperature alarms. Alarms and warning are signals in their own right that can be precented or cause processing. On an overheated system you will probably want to shut something down etc.
4 – Precentation is the easiest step as all you do is to forward a signal to a gauge.
A key rule is that 1, 2 and alarm processing is done at first possible point in a signal tree, preferable on the very device that collect the signal. If we assume this is a motor controller you would monitor temperatur and instantly shut off the PWM’s on the controller – you do not want to send the signal to a PC and wait 1-2 secs for temperature to shut down. But, assuming your temperature was collected on the PC through a different device that is exactly what you would be doing.
This second illustration adds the full picture including output signals and alarm processing. Alarms and Warnings are raised/cleared based on normalized input signals or user actions. They might be only precentations, they might be ignored or they might change the output processing like switching PWM’s off in my motor controller. The frontend will see backend as a local server node, but the actual processing will most likely be on a device near hardware due to reaction time.
In control systems we also treat communication itself as a signal – do we have communication or not? Communication itself is of less importance, but what is of importance is if we have control of the device from top-side and what do we do if we loose that control ?
Assume you have a fully electronic car with an electric steering-wheel – what do you want your car to do if the steering wheel (HMI) looses the ability to control your car?
I at least would like it to stop the car – this is alarm processing and why alarm processing needs to be close to the controlling input/output. Now – assume this was a aeroplane and the response would be different – you do not want an automated stop on an aeroplane – at least I don’t 🙂