Active

PICMG CTO Doug Sandy presents PICMG industrial IoT initiatives. The video was first presented at Embedded Tech Trends 2021.

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.

In my previous post, I discussed how PICMG was working on several specifications to accelerate the deployment of Industrial IoT applications.  Our work focuses primarily on interoperability at the sensor domain, where lack of standardization has been an impediment to wide-scale adoption.   This post describes in more detail how one of the PICMG specifications – MicroSAM™ — fills part of this need.  I will show how it fits by way of example.

A smart factory IoT installation can be viewed as consisting of many different layers.  At the highest layer are back-end and support functions including sales, procurement and business analytics.  Next comes operations of the plant.  Below that are individual pieces of equipment, which may be grouped into one or more lines of operation. The last layer is comprised of thousands of individual sensor nodes that interface directly with the sensors (e.g. temperature sensor, pressure sensor) or effectors (e.g. servo motor, solenoid) deployed in the factory.  This is depicted in the following figure.

MicroSAM fills a need not currently addressed by other industry specifications; namely, a compact module targeted at microcontrollers for each of the Industrial IoT sensor nodes.  As such, the processing performance and I/O connectivity are targeted toward the sensor interface.  MicroSAM may exist in parallel with other PICMG technologies, where MicroSAM devices provide sensor connectivity, and MicroTCA®, COM Express®, or CompactPCI® Serial provide higher layers of control.

MicroSAM extends and co-exists with the existing open-sourced microcontroller ecosystem by offering a standards-based solution that has been designed specifically for embedded use.  Some of its key advantages are:

• Full industrial operating temperature range
• Small size (32mm x 32mm)
• Low power consumption
• Power filtering and signal conditioning for embedded installations
• Reliable industrial-grade communications
• Direct connectivity to a variety of sensor types (analog voltage, analog current, digital)
• Latching connectors for secure connectivity
• PWM output for motion control applications
• Hardware interlock and trigger signals for multi-node synchronization

Perhaps the most exciting part about the MicroSAM specification that I can share with you is that it is going through the membership review process and is expected to be fully released in August 2020.  In my next post I will discuss how hardware abstraction and data modeling can be combined with the MicroSAM module to provide plug-and-play at the sensor layer.  Until then, I would love to hear your feedback.  What sensors or effectors do you see as most important?  Which MicroSAM features will best meet your needs?