How OPC UA and DDS Joined Forces Reply

opcuaAndDDSUniteBlog.jpg

It all started, appropriately, at National Instrument’s annual show called NIWeek in Austin, Texas. There, Thomas Burke, President & Executive Director at the OPC Foundation, approached me and asked if I was interested in helping build a partnership between the two most important connectivity solutions in the IIoT. Because of RTI’s leadership at the IIC and within DDS, we were well placed to lead.

That was the start of a great journey.

It was easy to agree to Thomas’s proposal. Both communities were struggling with how to differentiate our core value propositions. As everyone now knows, in practice, OPC UA and DDS solve very different problems. They focus on different industries. Even in the same application, they solve different use cases.

Nonetheless, the world thought we were at war. Why?   You need to understand the confusion of a new, very hot market. The Internet changed banking, retail, and travel agencies.  It created huge new companies and ended many others.  But, it didn’t touch most industrial applications.  Factories, plants, hospitals, and power systems operate today the same way they did 20 years ago.

Suddenly that is changing.  Gartner, the analyst firm, predicts that the “smart machine era” will be the most disruptive in the history of IT.  The CEO of General Electric famously said if you go to bed an industrial manufacturer, you will wake up a software and analytics company.  The modernization of the industrial landscape—the “Industrial Internet of Things” (IIoT)—will impact virtually every industry on the planet.

Mega trends that sweep through huge swaths of the economy like that always cause a lot of stress.

In this case, the stress was a perceived clash of industry alliances. The German industrial leadership has been developing a new architecture for manufacturing called Industrie 4.0. The German government invested over a billion Euros in Industrie 4.0 over most of a decade. Then, in 2014, five large US companies founded the Industrial Internet Consortium (IIC). The IIC struck a nerve in the market, and quickly grew to include hundreds of companies. Since both the IIC and Industrie 4.0 are working on “industrial systems” architecture, people assume they compete. A challenging reporter wrote an article on the implications for world dominance, and a conflict was born.

Then, that same reporter posted an opinion that the conflict was really technical, rather than political, and the most important technical conflict was between OPC UA and DDS. Suddenly, both communities were embroiled in controversy that made no real sense.

The rest, as they say, is history. Today, the IIC and Industrie 4.0 announced their cooperation. Their plan is to seek ways to combine Industrie 4.0’s depth in manufacturing with the IIC’s breadth across industries. The core technologies have similar strengths and similar goals.

Our path had its rocky stretches, but we are making great progress. We are working on mapping the architectures. The OMG has an official standards effort to define an OPC UA/DDS bridge. The OPC Foundation is building a “DDS Profile” for OPC UA pubsub. And, the IIC is creating joint testbeds that will prove the integration. We are, together, building the IIoT’s future.

The positioning document and press release going out today are the result of many people’s work. It combines input from the major DDS and OPC UA vendors, from the IIC and Industrie 4.0, and from the OMG and OPC Foundation standards organizations. I would like to particularly thank those most involved: Thomas Burke and Stefan Hoppe from OPCF, Matthias Damm from Unified Automation, and RTI’s Gerardo Pardo-Castellote. Coordinating all these organizations to make any joint statement would be impressive on its own. But, somehow, we managed the deep cooperation required to clarify the markets and design a technical integration. That’s because we all realized how important it is to build a standard, interoperable design that covers the IIoT. By coordinating our political leadership with the leading technologies, we will build, together, the future of the IIoT.

RTI’s 2015 and a Peek at 2016 Reply

2016YearInReviewBlog.jpg
Hello RTI Customer!

I will always fondly remember 1999 … at the peak of the dotcom boom. Our company, then focused on tools, was one of the fastest-growing in the frothy Silicon Valley market. The dawn of The Internet age was exciting, and we were along for the ride.

2015 may not have matched the hyperactive dotcom era. But, I will also always remember it as a standout year. It was a real turning point for RTI. It was by far our best sales and strategic year since the dotcom days. In particular:

  • Our expanded sales team turned in an impressive performance. We grew sales nearly 30%, easily exceeding our goals. And, two years in, it’s great to see customers flocking to our fair, simple and open subscription pricing.
  • The Industrial IoT and the Industrial Internet Consortium created a hot market. We are perhaps the best positioned of all small companies to ride and lead the IIoT wave.
  • Our great new products and features like security, better tools, queuing, easier installation, and safety certification help us explore this market like no competitor.
  • We now have experience with about 1000 applications, including surgical robotics, autonomous cars, drones, emergency medical systems, automotive testing, imaging, communications, operating room integration, video sharing, grid control, cancer treatment, oil & gas drilling, ships, wind turbines, avionics, broadcast television, air traffic control, SCADA, robotics, defense, and on and on. And on. Wow! The IIoT truly spans all industries.
  • We shared our story in dozens of webinars, conferences, and trade shows. My favorite? The Inside Story: GE Healthcare’s IIoT Architecture.

So, what about 2016? We expect another strong sales growth year. With our great new “Service Delivery Partners” like Tech Mahindra, we will offer a more complete solution. We will drive product quality and coverage to ensure we can meet our customers’ demanding use cases. We will hire many new teammates in sales, business development, services, engineering, and marketing (watch www.rti.com/jobs). These new resources will help us serve you, our customers, with better products and care.

Back during the dotcom boom, nobody could really foresee the transformative impact of The Internet. The shocking truth: the IIoT smart machine era will be an even bigger transformation. We are at the beginning of a new world of intelligent distributed systems. The IIoT will change every industry, every life, every application, and every job.

RTI is a real leader of this transformation. Our fundamental purpose is “To enable and realize the potential of smart machines to serve mankind.” We are now designed into well over $1 trillion worth of “things.” We are saving lives, improving efficiency, and ensuring reliability across an amazing slice of the new world.

To deliver on our purpose, we understand that, in the end, we must earn your trust. We accept that as a fundamental responsibility. I am continually grateful for your faith in us as your partner on the IIoT adventure.

Thank you,

Stan Schneider, CEO RTI


A Taxonomy for the IIoT Reply

Kings Play Chess On Fine Glass Stools.  Anyone remember this?

For most, that is probably gibberish.  But not for me.  This mnemonic helps me remember the taxonomy of life: Kingdom, Phylum, Class, Order, Family, Genus, Species.

The breadth and depth and variety of life on Earth is overwhelming.  A taxonomy logically divides types of systems by their characteristics.  The Science of Biology would be impossible without a good taxonomy.  It allows scientists to classify plants and animals into logical types, identify commonalities, and construct rules for understanding whole classes of living systems.

The breadth and depth and variety of the Industrial Internet of Things (IIoT) is also overwhelming.  The Science of IIoT Systems needs a similar organized taxonomy of application types.  Only then can we proceed to discuss appropriate architectures and technologies to implement systems.

The first problem is to choose top-level divisions.  In the Animal Kingdom, you could label most animals either, “land, sea, or air” animals.  However, those environmental descriptions don’t help much in understanding the animal.  The “architecture” of a whale is not much like an octopus, but it is very like a bear.  To be understood, animals must be divided by their characteristics and architecture.

It is also not useful to divide applications by their industries like “medical, transportation, and power.”  While these environments are important, the applicable architectures and technologies simply do not split along industry lines.  Here again, we need a deeper understanding of the characteristics that define the major challenges, and those challenges will determine architecture.

I realize that this is a powerful, even shocking claim.  It implies, for instance, that the bespoke standards, protocols, and architectures in each industry are not useful ways to design the future architectures of IIoT systems.  Nonetheless, it is a clear fact of the systems in the field.  As in the transformation that became the enterprise Internet, generic technologies will replace special-purpose approaches. To grow our understanding and realize the promise of the IIoT, we must abandon our old industry-specific thinking.

So, what can we use for divisions?  What defining characteristics can we use to separate the Mammals from the Reptiles from the Insects of the IIoT?

There are thousands and thousands of requirements, both functional and non-functional, that could be used.  As in animals, we need to find those few requirements that divide the space into useful, major categories.

The task is simplified by the realization that the goal is to divide the space so we can determine system architecture.  Thus, good division criteria are a) unambiguous and b) impactful on the architecture.  That may sound easy, but it is actually very non-trivial.  The only way to do it is through experience.  We are early on our quest.  However, significant progress is within our collective grasp.

From RTI’s extensive experience with nearly 1000 real-world IIoT applications, I suggest a few early divisions below.  To be as crisp as possible, I also chose “metrics” for each division.  The lines, of course, are not that stark.  But the numbers force clarity, and that is critical; without numerical yardsticks (meter sticks?), meaning is too often lost.

IIoT Taxonomy Proposal

Reliability [Metric: Continuous availability must be better than “99.999%”]

We can’t be satisfied with the platitude “highly reliable”.  Almost everything “needs” that.  To be meaningful, we must be more specific about the architectural demands to achieve that reliability.  That requires understanding of how quickly a failure causes problems and how bad those problems are.

We have found that the simplest, most useful way to categorize reliability is to ask: “What are the consequences of unexpected failure for 5 minutes per year?”  (We choose 5 min/yr here only because that is the “5-9s” golden specification for enterprise-class servers.  Many industrial systems cannot tolerate even a few milliseconds of unexpected downtime.)

This is an important characteristic because it greatly impacts the system architecture.  A system that cannot fail, even for a short time, must support redundant computing, sensors, networking, and more.  When reliability is truly critical, it quickly becomes a – or perhaps the – key architectural driver.

Real Time [Metric: Response < 100ms]

There are thousands of ways to characterize “real time”.  All systems should be “fast”.  But to be useful, we must specifically understand which speed requirements drive architecture.

An architecture that can satisfy a human user unwilling to wait more than 8 seconds for a website will never satisfy an industrial control that must respond in 2ms.  We find the “knee in the curve” that greatly impacts design occurs when the speed of response is measured in a few tens of milliseconds (ms) or even microseconds (µs).  We will choose 100ms, simply because that is about the potential jitter (maximum latency) imposed by a server or broker in the data path.  Systems that much respond faster than this usually must be peer-to-peer, and that is a huge architectural impact.

Data Set Scale [Metric: Data set size > 10,000 items]

Again, there are thousands of dimensions to scale, including number of “nodes”, number of applications, number of data items, and more.  We cannot divide the space by all these parameters.  In practice, they are related.  For instance, a system with many data items probably has many nodes.

Despite the broad space, we have found that two simple questions correlate with architectural requirements.  The first is “data set size”, and the knee in the curve is about 10k items.  When systems get this big, it is no longer practical to send every data update to every possible receiver.  So, managing the data itself becomes a key architectural need.  These systems need a “data centric” design that explicitly models the data thereby allowing selective filtering and delivery.

 Team or Application Scale [Metric: number of teams or interacting applications >10]

The second scale parameter we choose is the number of teams or independently-developed applications on the “project”, with a breakpoint around 10.  When many independent groups of developers build applications that must interact, data interface control dominates the interoperability challenge.  Again, this often indicates the need for a data-centric design that explicitly models and manages these interfaces.

Device Data Discovery Challenge [Metric: >20 types of devices with multi-variable data sets]

Some IIoT systems can (or even must) be configured and understood before runtime.  This does not mean that every data source and sink is known, but rather only that this configuration is relatively static.

However, when IIoT systems integrate racks and racks of machines or devices, they must often be configured and understood during operation. For instance, a plant controller HMI may need to discover the device characteristics of an installed device or rack so a user can choose data to monitor.  The choice of “20” different devices is arbitrary.  The point: when there are many different configurations for the devices in a rack, this “introspection” becomes an important architectural need to avoid manual gymnastics.  Most systems with this characteristic have many more than 20 device types.

Distribution Focus [Metric: Fan out > 10]

We define “fan out” as the number of data recipients that must be informed upon change of a single data item.  This impacts architecture because many protocols work through single 1:1 connections.  Most of the enterprise world works this way, often with TCP, a 1:1 session protocol.  Examples include connecting a browser to a web server, a phone app to a backend, or a bank to a credit card company.

However, IIoT systems often need to distribute information to many more destinations.  If a single data item must go to many destinations, the architecture must support efficient multiple updates.  When fan out exceeds 10 or so, it becomes impractical to do this branching by managing a set of 1:1 connections.

Collection Focus [Metric: One-way data flow with fan in > 100]

Systems that are essentially restricted to the collection problem do not share significant data between devices.  They instead transmit copious information to be stored or analyzed in higher-level servers or the cloud.

This has huge architectural impact.  Collection systems can often use a hub-and-spoke “concentrator” or even a cloud-based server design.

Taxonomy Benefits

Defining an IIoT taxonomy will not be trivial.  This blog just scratches the surface.  However, the benefits are enormous.  Resolving these needs will help system architects choose protocols, network topologies, and compute capabilities.  Today, we see designers struggling with issues like server location or configuration, when the right design may not even require servers.  Overloaded terms like “real time” and “thing” cause massive confusion between technologies with no practical use case overlap.

It’s time the Industrial Internet Consortium took on this important challenge.  Its newest Working Group will address this problem, with the goal of clarifying these most basic business and technical imperatives.  I am excited to help kickoff this group at the next IIC Members meeting in Barcelona.  If you are interested, contact me (stan@rti.com), Dirk Slama (Dirk.Slama@bosch-si.com), or Jacques Durand (JDurand@us.fujitsu.com).  We will begin by sharing our extensive joint experiences across the breadth of the IIoT.