Serious Human Interface™ Platform (SHIP) System Architectural Overview

From Serious Documentation
Jump to: navigation, search

The Serious Human Interface™ Platform (SHIP), is an integrated set of OEM-ready technologies to connect Industrial Machines to Humans wherever they are.

These technologies include:

  • Graphic/Touch front panel systems to deliver a modern interactive experience directly in front of the machine
  • Communications and control systems to connect/control 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

SHIP - the Big Picture

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

Start with an front panel "refresh" as the first step in the process, using Serious Integrated HMI Modules (SIMs) as a fast and cost-effective way to transform the at-machine experience, upgrading from an operator interface to a rich interactive encounter, unlocking the data and control capabilities trapped inside your industrial device.

Or decide to free up multiple software engineers on your development team by adopting a Serious Communications Module (SCM) and get out of the never-ending chore of OS ports, drivers, and hardware and software plumbing. Every SCM comes with out-of-the-box pre-licensed, pre-ported, and application-development-ready software, including a commercial, robust OS (Kernel, TCP/IP, TLS/SSL, USB, File System) as well as connectivity middleware, drivers, and more. Re-engineer the control and communications soul of your device with the Serious platform and focus your efforts on applications and new products!

Once your system has adopted the Serious Human Interface™ Platform as a foundational building block it is only a short step to get cloud connected with Serious Connect, the comprehensive IoT cloud dashboard and management system powered by Arrow Connect. Provisioning, administering, monitoring, controlling and even updating your devices from the cloud and your hand-held device has never been an easier next step for your products.

From start of design, to launch, production and evolution of your SHIP-based products, Serious is right beside you as a partner with technology onboarding, training and long-term support.

Our Launch program is designed to get your product re-engineered with SHIP technology and into production in a few short months.

Imagine your product elevated – graphic/touch enabled, cloud-connected, managed and over-the-wire upgradable – faster than you thought possible and with software and hardware engineering capacity to spare.

With SHIP and Serious as your partner, it’s possible.

The Evolution of Typical Industrial Machine Architectures

Let's start at the beginning and understand how we got to today with millions of industrial machines lagging so far behind the consumer device evolution. While consumer devices have become highly interactive, highly connected and available anywhere, most industrial devices are isolated from the cloud, operated from outdated front panels. And the cost of solving the engineering challenges to evolve and transform these industrial machines into highly interactive, highly connected devices keeps going up especially in the software arena.

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 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 IO system, typically with relays, sensor interfaces and analog front ends, evolves over time based on machine features and capabilities.

Traditional Machine Architecture

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:

Traditional Machine Architecture with Distributed Power/IO Subsystem

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:

Modern Fully Distributed Power and IO Subsystems

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. Many embedded 32-bit MCUs with on-chip FLASH and RAM are 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. Their solution is to embrace large, complex software frameworks Renesas in order to attempt to drive consolidation of the software implementation around a single large MCU with costs above $5 or even $10 or $15.

All of these efforts point to the biggest challenge as machines evolve: managing the exploding software complexity and development challenge.

System on Modules (SOMs) to the Rescue?

As any designer who has attempted to use WiFi chipsets directly in a design will attest, the associated challenges of wireless design certification - however difficult - were easier than the merging of the software stacks from the chipset vendor into the OEMs software architecture. As a result, WiFi chipset vendors have moved to a System on Module deployment model, enabling a small number of Original Design Manufacturers (ODMs) to integrate MCU, chipset, and software into a pre-certified off-the-shelf "System on Modules" or SOMs. OEM designers, rather than ground-up designs with chipsets and software stacks, now leverage the ODMs' integration and integrate and customize the SOM into their design for a small premium generally more than offset by the faster time to market and reduced engineering effort.

SOMs effectively have created a distributed processing architecture within OEM designs -- smart subsystems managed by the main control system MCU and interconnected with UART, SPI, or I2C ports.

While SOMs such as Bluetooth, WiFi, 4G LTE, and others have simplified the initial work of adding these capabilities to industrial systems, as the end-to-end requirements affect the software on the SOMs the software stack again begins to dominate the effort and expose limitations in the collection of SOMs assembled on an OEMs design. For example, many WiFi SOMs have built-in TCP/IP stacks making it easy to connect them to simple sensors or even more complex industrial machine MCUs with little overhead in the main MCU. However, adding the need for two-factor authentication, improved Transport Security Layer (TLS), and seamless handoffs from WiFi to other connections (Ethernet, 4G, Bluetooth) make the high-level stacks inside these SOMs unusable. The low level drivers and wireless certifications retain their value, but the system level software needs again push much of the complex software challenges to the main MCU and back onto the OEMs' shoulders.

SoMs to the Next Level - Intelligent Subsystems

The SOM concept is a good one -- distributing the software engineering burden out to the SOM manufacturer in order to reduce the unneeded complexity for the OEM of software development. It's just at the wrong level of granularity. For example, in the WiFi module case, moving the SOM functionality line from the WiFi stack and hardware to the communications hub level solves the seamless handoff and TLS issues by partitioning the TCP/IP stack at the right level to span the required peripherals -- Ethernet, WiFi, TCP/IP over 4G/LTE, etc. and unify the security stack, certificate, and authentication issues required to be IoT connected. Of course, not all machines need all these features, but the ability to seamlessly scale to various connectivity mechanisms without increasing the software burden on the OEM is a powerful concept.

Similarly, the modern graphic/touch Human Machine Interface (HMI) is a complex software and hardware subsystem that can be partitioned from the control system, offloading the burden of GUI management, the associated supporting file systems, event systems, data movement, and continuous hardware churn associated with the LCD supply chain. In the same way as a range of comms hubs can provide scalability in connectivity, a range of consistent HMI solutions can provide scalability in the front panel experience independent of the control system and the machine IO. Some OEM machines may be lower end, with a smaller, more cost sensitive front panel, where as the high end of the OEM portfolio may sport a larger HMI solution with advanced features and capabilities. While the software and hardware subsystems required to support this level of of HMI scalability are dramatically different, a SOM approach can isolate these differences from the OEM designer assuming the method for developing and communicating with these HMI SOMs is consistent across the range.

The Software Ownership Trap

The majority of software and hardware development continues to be in-house at OEMs, creating an ever-expanding codebase to manage and evolve. While the hardware team keeps up with expanding CPU, memory, and component supply issues, the software team is rarely sufficient to maintain, grow, and evolve the code as fast as needed to keep up with the market and with business desires. There are just never enough software resources.

The problem generally is not the OEM application itself, but rather the infrastructure and plumbing required to support the application's growing connectivity needs -- both local human connectivity via advanced HMI as well as to the cloud and the associated communications and security challenges.

MCU vendors supplying free libraries and pre-made software stacks, unfortunately, only exacerbate the problem. Their core business is silicon, not software and applications enabling, and the stacks are often little more than "as is" demo code with unpublished roadmaps -- try asking your MCU vendor for the release schedule and roadmap for their software stacks! -- unclear change management, and inadequate support. Unwittingly, OEMs outsource the foundational elements of their software strategy to a vendor whose core business is not software and application enabling. Initially, this works well for many OEMs. Certainly, the "free" aspect to these libraries is attractive. However, over time, the MCU vendors' software is changed, expanded, and rewired in the OEM's application to the point where effectively the OEM owns the maintenance and evolution of the whole codebase again.

Given the high cost of custom internal software development and the constraints on the business and product evolution because of these costs, it is surprising how few OEMs decide to incorporate commercially supported, robust, third party software such as an RTOS with associated stacks. Often a one time fee with ongoing maintenance subscription for a full-featured framework can be less than the cost of a single software engineer. Partnering with a world class embedded software vendor such as Segger can radically decrease the OEMs' software custom development efforts in areas that are completely outside the value proposition of the OEMs' core intellectual property. For example, a senior software developer's time incorporating, debugging, and maintaining a file system and associated low level drivers and stacks from MCU vendor demo code can be dramatically reduced to merely leveraging the Segger emFile file system and their pre-tested peripheral drivers, with the advantage of outstanding developer support, ongoing roadmap and bug fix releases, and high end features such as robust journaling for crash-resilience, flash wear leveling, and more that "free" stacks don't begin to offer. In addition, these RTOSs and stacks provide freedom from the specific MCU vendor, enabling the OEM to commoditize their MCU into raw horsepower, peripherals, and memory with a highly portable software stack.

As good as these robust, fully supported RTOSs and associated stacks are, they are still just ingredients waiting to be integrated, combined, and formed into an application-ready framework with a messaging, logging, upgrading, communications, version management, and more. Chip-level drivers have to be mapped to the specific OEM implementation and maintained. Is this plumbing and infrastructure also the inevitable burden of the OEM software team? Or is there another way that would empower the software team to spend a portion of its time incorporating more trusted, supported, commercial software and the vast majority of its effort actually evolving the machine and its application capabilities?

The Serious Human Interface™ Platform

Re-imagining the Local Human Machine Interface

Traditional Operator 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