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

Revision as of 06:42, 1 May 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 transformation 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.

Control Subsytem Elements

While the basic ingredients of the control system have not changed:

• IO monitoring, control, and sequencing
• Operator interface management
• External communications
• Optional machine accessory control

the requirements in each of these areas in a modern machine have dramatically increased.

IO Monitoring, Control, and Sequencing

The control system is normally responsible for sequencing the machine through its various operational states and substates. In basic machine architectures, the control system is directly reading sensors and firing actuators, whereas in more distributed/advanced architectures those sensors and actuators become separate and somewhat independently intelligent -- data can be preprocessed at the sensor (for example, turning a thermistor analog reading into a calibrated temperature) and the more abstract input/output data is used/manipulated by the control sequencing.

In most systems, the machine sequencer/monitor is a state machine software algorithm implemented as a task in an RTOS or an element of a super-loop. Sensors and actuators are polled or set in the loop directly, or in distributed IO architectures a central data structure of input and output "variables" is maintained by the control loop with a separate mechanism to synchronize these variables with the various remote IO elements.

Operator Interface

The operator interface in a typical machine is a collection of indicators (LEDs, digit displays,etc.) and switches/knobs including scanned membrane keypads etc. An RTOS task or a phase in the "super loop" software scans the various inputs, switches, keypads, etc, and sequences the indicators appropriately based on machine state. As the complexity of the operator interface rises, perhaps starting to use monochrome segment LCDs or even move to touch screen graphics user interfaces,the complexity and impact of the software and hardware needs of the Human Machine Interface (HMI) are highly disruptive, inevitably forcing a transition to a new class of MCUs with large memory and higher performance, The super-loop software architecture collapses under its own weight, becoming an unmaintainable tangle of embedded code, driving a transition to an RTOS kernel and repartitioning of the code as well as leveraging software libraries or expensive high level "GUI builders".

External Communications

Along with HMI, the communications and connectivity of industrial machines has seen more options and changes in the past decade than in all the prior decades combined. Of course, the tried and true RS232, RS485 and CAN communications ports continue to be widespread in use, inexpensive, and home-grown protocols and drivers abound. Nearly every modern MCU has native support for these.

But new connectivity options, including USB, TCP/IP (Ethernet, WiFi), Bluetooth, and many other technologies offer new ways to access and interact with machines. Over the wire/air updates, remote monitoring/control, PC and external connectivity, and inexpensive USB peripherals are powerful product capabilities albeit each coming with large software and systems architectural headaches, as well as further driving the complexity and power of the main MCU.

Machine Accessories and Inter-Machine Coordination

As the limits of HMI, communications, and processing capabilities are removed and the software architecture is re-invented to be more correspondingly modular and scalable, new machine configurations including post-sale upgrades and accessories as well as machine-to-machine coordination become possible, opening up new revenue models and features.

And then Came the Cloud: the Industrial Internet of Things (IIoT)

Just as industrial systems designers planned and began evolving their machines over the past decade, the world shifted. While internet connectivity has been a technically feasible option for industrial machines since the 1990s, the last decade has changed expectations and opened new options for OEMs through a whole new level of Human-Machine interactivity. Remote dashboards, analytics, predictive maintenance, monetized and franchised data, and many more capabilities are now an essential part of the feature roadmap for every industrial machine.

Cheap, Powerful MCUs and the Software Challenge

MCUs continue to grown in power and integration as the natural implications of Moore's Law continue and the desire of silicon vendors to upsell their customer base and increase content ownership on the BOM. 32-bit MCUs with embedded FLASH and RAM are well below $1, enabling powerful distributed architectures with little incremental cost. Larger MCUs a few decades ago would have been considered supercomputers on a chip -- the Renesas RZ A1/H, for example, has 10MB of internal RAM, a 400MHz ARM Cortex-A9 core, and an incredible array of on-chip peripherals.

However MCU vendors are grappling with the challenges of how to make money with highly sophisticated $1 MCUs when the adoption of these is slowed and filtered by engineering challenges far outside their domain: the thousands, if not millions, of lines of software needed to make all these features work.

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