At what point does a sensor become an embedded device or is there a difference? So for example the tire pressure device in your car’s tires, is it an embedded device or just a sensor, and how do you make the distinction between the two?
This topic came up when talking about OS’s and if embedded devices have or need an OS.
This question comes up regular on some of the groups on LinkedIn.
An embedded device does not always need an OS. It all depends on the requirements for the code and if there is stuff like TCP/IP and networking etc. This is where I see the need for an OS as there are a number of tasks that need to co-operate. That’s my view on it anyway.
I have many embedded devices that are running well without any OS but they are not using any networking.
@ Dave McLaughlin - So, according to your definition would the NETMF runtime be an OS or is a NETMF app that uses networking not an embedded device?
I haven’t really given this much thought yet but my first instinct is to say that a “sensor” is too broad a term that could include anything from a simple analog component to a full embedded (or non-embedded) device. Anything that is capable of measuring (or calculating) something and communicating that back to another system can be considered a sensor in my mind. If I have a webcam connected to my laptop and OpenCV running facial recognition and I have it raise an interrupt via serial port to another device when I enter a room, does my entire laptop not become a sensor?
This is why it gets messy! 
I still consider NETMF as a type of OS, although it doesn’t actually have one as such. It includes backend stuff that allows pre-emptive tasks to run in much the same was as a Real Time OS would.
For most smaller and simple devices such as a sensor that has a microcontroller, a simple state machine can do all the work.
Told you it gets messy.
I would say that a sensor is capable of measuring a quantity and producing an output that can be read by another device or instrument. The output can be analog or digital. The sensor will not have any function to process this measurement. It is up to the reader to calculate, interpolate and take action.
However if the sensor coexists with a processor (discrete or programmable) and is able to read one or more quantities (e.g… pressure and temperature) perform rule based calculations (e.g… compensate pressure at a particular temperature) and take appropriate action like transmitting a tire pressure ok, not ok or fatal status to the dashboard controller or the cars master to display a dashboard alert. This implementation is autonomous for a function (e.g… tire pressure monitoring) - we have an embedded device instead of just a sensor.
Is an OS required ? or may be the question could be “is an RTOS required ?”. This depends on the function(s) required to be performed by the device. If there are multiple tasks performed by the device and there is a need for each task to be serviced in guaranteed real time, then a RTOS is required e.g. ensure that temperature, pressure and speed are monitored once every 30ms. In case of any anomaly of tire pressure stop all tasks and signal the fatal alert task (to reduce speed, engage braking, light up dashboard indicator, signal all-star (or other)).
A sensor and an embedded device are not mutually exclusive.
There are smart sensors that process/store/send the data and they sure are an embedded system but are still called sensors.
I would say that as long as an embedded device measures some part of the environment it’s in and stores/sends/processes the data in some way, it is also a senor.
So, not all sensors are embedded systems and not all embedded systems are sensors but there are sensors that are embedded systems and embedded systems that are sensors. 
Is ‘networking’ limited to TCP/IP or does it include any communication such as Bluetooth or as in the case of the tire pressure sensors UHF RF?
Embedded devices could be anything from a full blown computer system built into wall to a pressure sensor, which is perhaps by design so IoT promoters can make outrageous claims as to the number of devices in use currently and thought to be in use in the future. Its a messy definition at best. In some ways this is why I like Microsoft’s approach to the problem, in that there is no one answer so you have a whole bucket of options depending on how much OS you need, but yet they are all common enough and use the same tools that your skill set is still applicable at any level.
It seems that tire pressure sensor are a little more complex then just a dumb old pressure sensor as they often have temperature and one or two axis accelerometers in them as well and I believe that for example in Microchip’s sensors they are running Green Hills Software Integrity RTOS. The sensors in this case response to a request for information via a 125kHz ASK modulated signal, so much for just a dumb old sensor.
Simplistically, I think of it this way.
A sensor can report on what it is tasked to measure. That could be tyre pressure or temperature or both. It can react to it’s data - for example, it might be programmed to report an alert if above/below a threshold. It cannot act on that data in a control way - it can’t run a pump to inflate the tyre for example.
A sensor needs to have an “interface”. That can be simple, I2C or SPI, or it can be complex, CAN, RS485, serial, Bluetooth, RF, TCP/UDP, HTTP… but the data you can get is “simple” - just what the sensor can read.
<insert grey area here >
A embedded device can use sensors, or aggregate data from multiple sensors, and act in a higher manner. This might mean it can detect the temperature, but may also be able to perform actions on it, turning on a fan or heater for example, or it can tell the temperature from one sensor and the fan RPM from a different sensor and can then calculate the required voltage to change the fan speed to achieve a temperature.
As an embedded device is usually operating at a higher level than a sensor, it often is interfaced at a higher level as well - so it may be “human readable” and not just machine-2-machine readable. This means it has a higher-level interface and not just a way for an upstream system/device to see the value.
simple, eh !
I would say:
If the sensor makes a decision, like tire pressure ok/not ok, then it’s an embedded device.
If it’s just sending the pressure to something else, then it’s just an sensor (even if it has a CPU to do so.
I agree with Reinhard, in the way that if the sensor only measure and give a value representing this measure, we can consider it is not an Embedded device, as for me, a device means a program, even if there is a couple of raws in it…
After thinking more about this, I’ve come to the conclusion that these terms should not try to be used mutually exclusively. A sensor can be an embedded device and an embedded device can be a sensor.