Minimum IoT scope? Example: Is a car an IoT already by itself? [closed]

Question

A car can be considered a "thing" in an Internet of Things. It does provide operational data to its manufacturer, is able to do emergency calls, can receive remote updates, etc.

Looking at the car "thing" more in detail however, it itself is comprised of many different things again. Its internal things are communicating, interacting with each other via their own network (CAN or Flexray).

Examples:

• a seat, which is informing others when being seated
• a steering wheel, which tells when being gripped, able to forward user commands
• a tire, providing pressure data
• a mirror, dynamically adapting to lighting conditions, providing environmental data

Just going by the definition, can a car by itself be considered a small scale IoT?

Answer 1

The car would not be an internet in itself, in my opinion. To qualify as internet, a network would need to extend beyond small boundaries such as a car. Let me explain.

So, yes, the car has a network of connected sensors and controllers. It may even connect these by ethernet internally and use TCP/IP and even MQTT. But from an IoT endpoint perspective, the car is probably one or a few endpoints. i.e, there's one/few controllers that collect metrics and sends it up. If there's remote features such as remote lock/unlock, that controller will handle the incoming messages. This is done from a security perspective and an API perspective (to enable information sets and business rules).

So, from a remote endpoint, you will probably command it like: SetTirePressuresPSI(LeftFront, RightFront, LeftRear, RightRear) Another way for the car IoT design would be to allow each tire pressure controller to be a thing on the internet, capable of talking to the cloud directly. Then, you'd have to send 4 separate messages remotely, which may leave the car in an unstable state if you lose connectivity in the middle. With the command to set them together, the pressures can be brought up in a way where the car is stable at all times. Maybe it can also be prevented if the temperature is above a certain limit, etc. (business rules at the edge)

So, you'll have either one controller for the car or one controller for some set of subsystems. This gets into the area of API design and choosing the right level of granularity.

There is a similar situation with buildings, rooms, sensors, switches, lights, etc. There's relationships among all these and the cloud world may know about them too. But in this case, it is ok for each device to be connected to the cloud. The security and safety implications of lights and temperature settings are far less troublesome.

When you use a protocol such as MQTT, you can build some addressing in the topic such as CARSerNum/Controller/Command where the message can be about the domain but the pub sub system allows you to implement that with various deployments. i.e, a site controller where there is one IoT endpoint or via various controllers each being an endpoint.

AWS recently released a new tool called twinmaker which you may find fascinating. Check it out. https://aws.amazon.com/blogs/iot/introducing-aws-iot-twinmaker/ It allows one to think in terms of real world objects, messages and topics. The actual IoT network deployment to achieve that is flexible.