Blog

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?

Imagine a factory in the near future, where front-end operations are seamlessly integrated with back-end purchasing and accounting using standard IT technologies. Artificial intelligence and machine learning provide actionable business insights, and new custom equipment is deployed using off-the-shelf smart sensors and motors with the same ease as you might install a new mouse with your laptop.  This is the vision of the Industrial Internet of Things (IIoT) “Smart Factory”.  

While many of the technologies to implement this vision exist today, standardization – particularly at the sensor domain – remains an impediment to wide-scale deployment.  This is where PICMG comes in.

PICMG is currently working on a series of specifications that are targeted at interoperability at the sensor domain.  The first of these specifications defines the Micro Sensor Adapter Module (MicroSAM™).  MicroSAM is a new hardware form-factor that is about the size of a postage stamp and answers the need for scalable, industrial-grade interface and data acquisition.  Other specification work includes requirements for common firmware features, common data model, network architecture, and integration with the Distributed Management Task Force’s (DMTF) Redfish management API.  Together, these form the backbone of plug-and-play for industrial sensors and actuators.  In a series of forthcoming blogs, more details will be given on each of these works.

We believe that PICMG IIoT compliant solutions will accelerate the uptake of smart-sensor technology by creating new, standards-driven engagement models that are based on interoperability.  These are just a few examples:

1. Traditional sensor vendors will be able to quickly create smart sensors by integrating their products with off-the-shelf sensor adapter modules and firmware.
2. Traditional microcontroller vendors will be able to produce hardware and firmware that interoperates with higher levels of the network with plug-and-play ease.
3. Facility operators will be able to deploy a wide range of sensors and actuators using PICMG extensions to the DMTF Redfish API without having to worry about the hardware device-specific behaviors.

Whether you are a computer hardware vendor, sensor vendor, integrator, or operator, these specifications have something to offer.  Before my next blog on MicroSAM™ and hardware at the sensor node, I would love to hear from you.  What challenges are you facing in Industrial IoT?  How can we work together to make your vision a reality?