A group of ancient philosophers and a mathematician (an engineer of the day) enter a room. The philosophers are engaged in a familiar debate. “What is a chair?” asks the first philosopher to the others. “In its very essence, what properties describe chair-ish-ness?” asks the second. The third chimes in: “Is a chair defined by its function and/or purpose, or something else?” Shaking his head at the still-standing philosophers, the mathematician walks to the nearest bench and sits down, declaring “If this isn’t a chair, it’s good enough for me.”
While this short story may seem a bit foolish, lately I find myself in the unlikely shoes of the philosophers from the tale. Within the PICMG IoT Network Architecture and Data Model technical subcommittee, we are asking the same questions, namely: “what is the general form of a sensor or effector (motor)?”, and “what properties are needed to encompass the variation that we see across sensors or effectors?” Answering these two questions, along with generalizing the behavior of the device, constitute the work of “data modeling” and are at the heart of PICMG’s strategy for interoperability in IoT. Let me explain how.
Suppose we are designing an IoT-enabled piece of factory equipment that has need for a motor. The role of the motor is to move to a specific rotational position as fast as possible. In this simple use case, it accepts one parameter (position) and performs one action (moves to the specified position), as shown in the following figure.
In creating this simple generalized motor model, we have also abstracted away hardware-specifics. It does not matter whether the motor is a servo or a stepper – if the behavior coincides with our model, either might be acceptable. Likewise, the vendor of the motor does not matter either. So long as the motor provides the same behavior as dictated by the model, interoperability is achieved.
Of course, real motor use cases are somewhat more complex than the one we outlined above. Motors can be used to do more than just move to a specific position. They can be used to rotate at a constant speed, follow complex motion profiles, and even synchronize their motion with other events. Precision, error, and torque characteristics may also be important. This points to the need for a more complex behavioral model and more operating parameters, but results will be the same – a generic data model, hardware abstraction, and multi-vendor interoperability.
The PICMG IoT Network Architecture and Data Model technical subcommittee is currently working on data models for generalized sensors and motion control.
If you would like more information on this work or would like to join in the effort, please contact me. Feel free to send me your reactions – I would love to hear from you.
