Difference between revisions of "Serious Human Interface™ Platform (SHIP) System Architectural Overview"

Revision as of 05:47, 30 April 2017

The Serious Human Interface™ Platform, or "SHIP", is an integrated collection of capabilities to connect Industrial Machines to Humans wherever they are. These capabilities include:

• Graphic/Touch front panel systems to deliver a modern interactive experience directly in front of the machine
• Communications systems to connect the machine, the front panel, and the cloud as well as other networks
• Cloud based systems, including over-the-air/wire updates, dashboards, analytics, provisioning, security, data piping, tablet/phone connectivity, and more to connect humans to the machines remotely

As an OEM systems designer, you can select from this collection of capabilities to evolve your Industrial Machine to a highly connected, interactive product.

Often OEMs start with the front panel "refresh" as the first step in the process, using the Serious Integrated Modules (SIMs) as a fast and cost effective way to transform the in-person human machine interactivity. Others start with a more subtle architectural change, using the Serious Communications Modules (SCMs) to re-engineer the insides of the machine in preparation for being cloud connected, reduce cost, and enable software and system scalability in the future.

The Evolution of Typical Industrial Machine Architectures

Many existing machines have a fairly straightforward "operator interface" with buttons, LEDs, and perhaps a small text display for basic menus, configuration, and status information. The central unified Microcontroller (MCU) is the focus of the OEMs' software teams, constantly refining, debugging, and updating the firmware for various machines, sharing and managing legacy codebases and looking to extend functionality and especially connectivity. The I/O system, typically with relays, sensor interfaces and analog front ends, evolves over time based on machine features and capabilities.

Separating Control from Power/IO

Many OEMs, over time, find the sophistication of the Control subsystem increases at a faster rate than the Power/IO subsystem driving a continued investment in software (and larger/faster MCUs). This subsequently leads to a realization the Power/IO subsystems are more naturally separated from the Control subsystem physically:

This is similar to what has happened in the automotive industry, where the I/O systems have completely distributed into intelligent sensors and actuators on a CAN network and managed by a main machine controller system, sometimes even layers of control systems (e.g. braking control which manages an array of sensors and actuators). This change leads to several positive outcomes for the system designer:

• The Control PCB technology can moves to finer pitches, denser SMT type packages, and lower voltages leaving the Power/IO PCB to more naturally stay with a heavier PCB to support larger components with higher voltages and coarser pitch trace, with a mix of SMT and through hole assembly.
• With very inexpensive <$1 32-bit MCUs now available, the Power/IO subsystem can be somewhat intelligent doing some well-measured real time sequencing of key events and providing safety-interlock capabilities where appropriate. Typically the software here is minimized, well reviewed, and changes little.. the goal is a solid, reliable, and straightforward IO system that requires little ongoing software development/maintenance.
• The separation of the Control and Power/IO also frees up physical restrictions in the enclosure, allowing the Power/IO board to be down/at the back of the machine where power enters and sensor/actuator wiring is performed, and the Control system can be co-located with the Human Machine Interface solution at the front of the machine
• In some rugged environments, the Power/IO board may require conformal coating etc., as it generally exposed to the inside of the machine whereas the newly separated Control board may be able to, through subenclosures, skip this expensive requirement.
• The partitioning of the software between the Power/IO and Control subsystems enables scalability in the Power/IO subsystem to be more abstract, and not require PCB and software churn in the Control subsystem and vice versa. Different machines can have larger (or alternatively smaller, cost reduced) Power/IO subsystems without changing the Control system. Similarly, the Control system can be upgraded and have different variants without changing the wiring or Power/IO section of the machine, allowing far more simple retrofit upgrades as well as product line segmentation.

Often OEMs leverage off-the-shelf CAN or RS485 differential wiring and transceivers for inexpensive yet highly robust communications inside the system enclosure to connect the now-distributed Control and Power/IO subsystems. Typically OEMs home-grow their own small custom protocol that abstracts the IO similar to what would exist in a Programmable Logic Controller where inputs and outputs have predetermined addresses and data types. For example turning on a relay would involve the Control MCU sending a command over the CAN/485 bus to the Power/IO MCU of "set output 43 to 1". Similarly inputs may be polled in a master/slave protocol topology, for example "get input 34 which is a floating point value of an ADC input".

The protocol is always a challenge. Master/Slave polled protocols, such as Modbus, are very simple to implement but have the inherent challenges of latency, limited data type support, and no off-the-shelf mechanisms for being able to push new firmware down to the slave(s) to enable centralized update management from the Control system. Gone are the days of replacing DIP EPROMs for firmware updates, and the system design must solve these issues in any modern design. This inevitably entails either more sophisticated custom protocol development, perhaps including bidirectional multi-drop multi-master protocols where the Power/IO board can spontaneously push input changes to the Control board without the polling requirement and associated latency, as well as boot loader and other facilities for firmware updates over the wire.

Fully Distributed Power and IO Subsytems

While even the first step of this topological evolution with a simple separate of Power/IO and Control boards yields great results for the system designer and the evolution of the product line as a whole for the OEM, the evolution can continue to its logical conclusion where the Power system is separated from the IO system, and the IO system is made hierarchical and fully distributed, enabling subsystem level scalability across machines, excellent unit and subsystem-level testability at the design and manufacturing stages, and easy/more robust machine wiring and maintenance:

In this model, the hub-and-spoke wiring model of the IO board controlling all the sensors and actuators is broken, with sensors/actuators being independently (and minimally) intelligent on the internal control bus, taking their power from a separate power bus routed throughout the machine. The use of "large IO boards" reduces, enabling:

• faster and cheaper diagnostics and maintenance when a sensor or actuator fails
• significant scalability and evolution of machine types and capabilities through the simple addition/removal of mechanical and associated sensor/actuators on the bus
• sensor/actuator abstraction, enabling multi-vendor sourcing and scalable capabilities (e.g. an inexpensive somewhat precise thermistor could be scaled to a highly precise temperature measuring system with the same abstraction)
• Reduced churn in large/complex IO PCBs
• Vastly simplified machine wiring and debugging on both the control bus as well as power system issues
• Significantly improved system assembly and manufacturing times and sensor- and subsystem-level diagnostics and testability

As mentioned, this is neither new nor a radical concept: the automotive industry made this architectural change decades ago for exactly these reasons and modern industrial machine designers are standing on the shoulders of these learnings as they evolve their own products.

Re-imagining the Local Human Machine Interface

Even this interface shown is more advanced that some, but the system architecture of many existing machines is a monolithic software and hardware structure:

From an Operator Interface to a Human Machine Interactive Experience