For most people, the home smoke detector is the first Internet of Things #IoT sensor/device they’ve ever come in contact with.
It may or may not CONNECT to a remote monitoring service over the Internet.
It COLLECTS air.
It ANALYZES the air looking for smoke using either an ionization chamber or photo-detector.
It ACTS on the insights derived from this analysis and sounds an alarm if smoke is detected. The battery on this device typically lasts a year before the annoying beeping sound begins.
Amazingly, this self-contained IoT device and analytics platform doesn’t require mythical AI powers to deliver value to the customer.
Don’t overthink it.
The static properties enumerated by a #DigitalTwin model represents #IoT #data that typically doesn’t change. #IIoT
In my last two posts about defining Digital Twin models for your IoT system, I described “telemetry properties” that map 1:1 with device sensors and their associated data types and units of measure. I also described “virtual properties” that are a sort of “soft sensor” whose value is derived through a calculation from sensor values and other data sources.
Today I’m adding “static properties” to your Digital Twin model which are values that typically don’t change. If I use a car as an example, static properties could be things like the length of the car, the number of cylinders, displacement of the engine, and the volume of room in the trunk. Static properties are necessary to have a more complete view of the actual entity (car in this case) and to be used as reference data for analytics when defining the Digital Twin model that instances of Digital Twins will be derived from.