RTI Connext on Snappy Ubuntu Reply

Snappy Ubuntu Core is a brand new version of the Ubuntu Linux operating system with transactional updates. Mark Shuttleworth, founder of Ubuntu and Canonical, introduced Snappy during his keynote presentation at the 2015 Internet of Things (IoT) World conference in San Francisco. There he highlighted efforts to create an open platform that supports developer innovation and opens new markets to device and software creators. Snappy applications (Snaps) are isolated from one another completely, just as on the Ubuntu mobile phone, making it much safer to install und upgrade applications independently from each other and Ubuntu Core. RTI Connext is the perfect communication platform for applications that can evolve and be upgraded independently. Here’s why:

  1. RTI Connext DDS provides a solution optimized for communication between Snaps on the same node as well as different nodes.
  2. RTI Connext meets the demanding performance, reliability and security requirements of Snaps.
  3. RTI Connext running on Ubuntu Core allows smart appliances to leverage real-time connectivity for the Industrial Internet of Things (IIoT).
  4. RTI Connext runs on many platforms besides Ubuntu Core and therefore supports interoperability between platforms.
  5. RTI Connext provides mechanisms to interoperate with different technologies and protocols.

At IoT World, Ubuntu showcased several different Snappy-based applications. An overview of the different applications can be found here.


An RTI demo as part of the IoT demo display at Canonical’s booth at IoT World.

At IoT World, RTI demonstrated how two Snaps can communicate with each other using an OWI Robotic Arm. The robotic arm can be controlled through USB. In the demo setup the USB interface is connected to BeagleBone Black, an open-source development board, running Ubuntu Core Snappy as its operating system. BeagleBone Black runs the controller Snap which subscribes to commands using RTI Connext and then sends the control commands to the robot arm through USB.

The Advantech Intel gateway, which has an Intel Atom E3800 processor, runs Ubuntu Core Snappy and the Robot command Snap. The Robot command Snap has a command-line interface through which commands can be entered, like turn clockwise, turn counterclockwise, and open grip. The commands are then published on the data bus. Using RTI Connext allows the controller and command Snaps to be co-located on the same node (BeagleBone) or different nodes (IoT gateway and BeagleBone) without having to change any of the Snap configurations. Below is a diagram of the demo setup.


More about RTI’s presence at IoT world can be found at http://blogs.rti.com/2015/05/12/sneak-peak-internet-of-things-world-conference-in-sf/ and http://blogs.rti.com/2015/05/18/day-two-at-iot-world-using-dds-to-make-smart-window-shades-even-smarter/.

What’s Fueling the Adoption of DDS in the Industrial IoT? Reply

The Internet originally evolved to connect human beings, regardless of their physical location or computing environments. By contrast, the Industrial Internet of Things (IoT) connects devices and systems and calls for unique connectivity technologies.

The connectivity technologies required for the Industrial IoT must be based on a foundational standard, which begins with an understanding of the architectural role, model, rules, and patterns in current industrial systems:

  • Architecture Role: Within the Industrial IoT, one of the primary roles of the connectivity architecture is to ensure interoperability (full plug-and-play compatibility) and thereby reduce integration time.
  • Architecture Model: Interoperability requires the introduction of connectivity gateways to address the diversity of devices in modern systems. Gateways serve multiple purposes, including support for external systems and devices that rely on other connectivity technologies. Gateways can also be used to create hierarchical architectures and to group various endpoints and devices into subsystems, as shown in the following diagram.


  • Data-Centricity Rule: Unlike human-driven environments, industrial systems operate autonomously and therefore call for a data-driven architecture. Within the Industrial IoT, data-centric communications can promote interoperability, scalability, and ease of integration. A data bus decouples data from application logic, and it allows dynamic data in motion to be more effectively managed and scaled.
  • Data Flow Patterns: In conventional enterprise IT environments, the data architecture deals with events, queries, transactions, and jobs. In the Industrial IoT, which is made up of a broad range of devices, the fundamental building blocks include streams of data, commands, status (or state) information, and configuration changes.
  • Event Triggers: The key activity triggers within conventional environments involve human requests or responses (decisions). In the Industrial IoT, activity is triggered by data or state changes that exist and happen autonomously.

Problem Solved: DDS Emerges as Connectivity Standard in the Industrial IoT

Currently, more than a dozen DDS implementations have propagated the standard into hundreds of system designs in healthcare, transportation, communications, energy, industrial, defense, and other industries.

Currently, more than a dozen DDS implementations have propagated the standard into hundreds of system designs in healthcare, transportation, communications, energy, industrial, defense, and other industries.

The Data Distribution Service (DDS) standard uniquely addresses all of these architectural considerations for the Industrial IoT.

The success of DDS in the Industrial IoT stems from the standard’s ability to connect everything, everywhere with a shared data model and open data bus. Seamless data sharing can be achieved with DDS regardless of proximity, platform, language, physical network, transport protocol, or network topology.

DDS can act as the core connectivity model within large, complex systems. For maximum interoperability between subsystems, a DDS Routing Service introduces a gateway capability. This feature makes it possible to organize data bus hierarchies, and also enables bridging or mediating between different data models, protocols, or security domains. A DDS Routing Service can isolate and filter content, so that sensitive information can be delivered without broadcasting it broadly across all busses.

Data Centricity vs. Message Centricity Reply

In this blog post, I would like to clarify the difference between data-centricity and message-centricity when it comes to middleware solutions.

Let’s consider DDS as an example of data-centric middleware and MQTT as an example of message-centric middleware. There are definitely other examples, and all middleware solutions have advantages and disadvantages. They are designed to tackle different use cases, and there is no one-size-fits-all solution.

DDS is a standards-based publish/subscribe integration infrastructure for critical applications of the Industrial Internet of Things (IIoT). It is neither just a middleware solution nor an SDK. One of DDS’s strengths is its data-centricity. MQTT, on the other hand, is a publish/subscribe integration infrastructure for commercial IIoT. Its strength is in its simple and lightweight messaging protocol designed for constrained devices. Both DDS and MQTT are designed for use cases that need to run under low-bandwidth, high-latency or unreliable networks.

To illustrate the difference between data-centricity and message-centricity, let’s consider the following two approaches to Calendaring, a common, everyday process:

Alternative Process #1 (message-centric):

  1. Email: “Meeting Monday at 10:00.”
  2. Email: “Here’s dial-in info for meeting…”
  3. Email: “Meeting moved to Tuesday”
  4. You: “Where do I have to be? When?”
  5. You: (sifting through email messages…)

Alternative Process #2: (data-centric)

  1. Calendar: (add meeting Monday at 10:00)
  2. Calendar: (add dial-in info)
  3. Calendar: (move meeting to Tuesday)
  4. You: “Where do I have to be? When?”
  5. You: (check calendar, contains consolidated state)

The difference between these two scenarios is “state.” In the data-centric approach, the infrastructure consolidates the changes and maintains them. DDS’s approach to implementing data-centricity allows applications to be integrated easily into the information-data model without forcing the application developers to write serialization/de-serialization code, and without forcing them to maintain state or make custom mappings. DDS directly supports data-centric actions such as create, dispose and read/take.

Data types are captured in DDS as topics. Topics define a name, type (including a key) and Quality of Service (QoS) settings. Data instances are managed by topic keys. The rich set of QoS settings control data availability (durability, lifespan and history), delivery (reliability and ownership) and timeliness (deadline and latency) via xml profiles. This approach immensely reduces the amount of code written and maintained by application developers.

Below you will see how much code must be written to implement the above scenario by utilizing data-centric middleware solutions such as DDS versus message-centric middleware solutions such as MQTT. As seen below, in the case of MQTT, the application developer needs to maintain the code to create an application-defined Collection to hold agenda items, deserialize bytes in the message, insert or replace in the Collection and lookup in the Collection.

Using Data-Centricity: Rich QoS –> less code to maintain data state

QoS for topic (i.e. data type): 


Code to maintain data state: none, as the middleware maintains data state:

  1. create DDS DomainParticipant to join DDS Domain
  2. with DomainParticipant, create DDS Topic “MeetingTopic” and DDS Subscriber
  3. with Subscriber and MeetingTopic, create DDS MeetingTopicDataReader
  4. when requested by user for agendaId:
        MeetingTopicDataReader.read(in agendaId,
        out {meetingId, meeting time, date}[])

Using Message-Centricity: not so rich QoS –> more code to maintain data state

QoS for message:

Chose one of the three below:

  • At most once. The message is delivered at most once, or it is not delivered at all.
    • QoS=0
  • At least once. The message is always delivered at least once
    • QoS=1
  • Exactly once. The message is always delivered exactly once
    • QoS=2

Code to maintain data state:

  1. create MQTT Client to connect to server (IP address or host name) and port number
  2. create application-defined Collection to hold agenda items
  3. with MQTT Client, subscribe to “MeetingTopic”
  4. when message received by MQTT Client:
    • invoke application code to deserialize bytes in message to get {agendaId, meetingId, meeting time, date}
    • insert or replace in Collection {meeting time, date} for agendaId, meetingId
    • when requested by user for agendaId:
    • lookup in Collection all {meetingId, meeting time, date} for agendaId

In this case, the application developer needs to maintain the code to create an application-defined Collection to hold agenda items, deserialize bytes in the message, insert or replace in the Collection and lookup in the Collection.

Day Two at IoT World: Using DDS to Make Smart Window Shades Even Smarter 1

The second day at IoT World was as busy and exciting as the first day. We had good traffic at the RTI booth and many interesting conversations with people of different backgrounds on a range of topics: semiconductors, sensors, energy, telecommunication, robotics, automotive, embedded software, mobile devices, testing, management software, data storage, and on and on. Though only a small percentage of people knew about RTI prior to the show, most of our booth visitors had no problem quickly understanding the role of RTI in the world of IoT and the value DDS brings to the IoT community.

Here is just one example. One visitor’s company manufactures “smart” window shades. (Remember: in the IoT world, everything is smart!) How would DDS apply to his world?

This company’s shades open and close based on input from sensors in the room. These sensors may track temperature, movement of objects (people), and light level. There may also be other sensors in the room to track conditions that could potentially contribute to the “decision” of the shade to open or close as well of the time and speed of that action.

How do the shades respond to these sensors? Should they consider all sensors, or only a select set? Can new sensors be added to the environment? Should the shades change their behavior in different kinds of rooms or different geographic locations? Can room conditions be recorded and analyzed by a controller application (perhaps running in the cloud?) to help the company to make maintenance and service decisions or improvements to its product?

DDS can play a key role in enabling data-sharing between the sensors and the controller app. Because DDS uses a data-centric approach, it does not require different sensors from different manufacturers to know about each other, nor is a discovery process required. Also, creating an application is easy because no point-to-point connection is required at the application level. DDS does it all under the hood.

RTI Connext DDS builds on this communication standard a rich set of QoS specifications that applications can tailor for their unique requirements. For example, an application can filter data from certain sources or with certain characteristics.

Interestingly enough, once the DDS story is told in the right context, it “comes to life” quickly for most people, and they get really excited. The window shade example might be not be the most typical use for DDS. But in the brave new world of “making everything smart,” it is not possible to imagine every scenario in which the technology will be applied.

Ubuntu and RTI: Going Beyond Smart to Brilliant

For Mark Shuttleworth, the “daddy” of Ubuntu, “making everything smart” is just not good enough! In his provocative and fun IoT World keynote, “All Things Smart,” he insisted on making all things “brilliant.”

photo (6)

Mark’s keynote highlighted the efforts of Ubuntu to create an open platform that supports developer innovation and opens these new markets to device and software creators.

Ubuntu’s booth at IoT World featured several RTI-powered, DDS-capable devices and applications.

photo (4)

RTI is proud to be part of this innovation making the vision of Ubuntu’s founder a reality!

Sneak Peek: Internet of Things World Conference in SF! 1

photo 1

Today is the opening day at Internet of Things World Conference in San Francisco. RTI is excited to bring to the event two live product demonstrations. Both will be shown in the RTI booth at the conference expo by RTI product manager Burcu Alaybeyi.

Here is the sneak peek of what you will see.

The first demo features Open Integrated Clinical Environment (Open ICE). In this environment, medical devices such as pulse oximeters, ECGs, infusion pumps, etc., from different vendors can publish data to a logical data bus (RTI Connext DDS) by conforming to a common data model. The demo includes a supervisory application that conforms to the same data model, which allows the sample application to subscribe to topics that the medical devices publish to.

DDS makes it much easier to develop medical device interfaces and medical supervisory applications, and Open ICE is an excellent example of medical device interoperability enabled by RTI Connext DDS. You can see a full demo of the PCA Safety use case here: https://vimeo.com/77127942. References and more info on the Open ICE initiative and medical device interoperability are available at mdpnp.org and openice.info.

The second demo shows robot arm control using DDS as data bus. This is a demonstration of how different SDKs, APIs and interfaces can be utilized to write RTI Connext DDS applications. In this demo, we use an RTI DDS LabVIEW VI to publish what the user wants to do with the robot arm. In this scenario a Python DDS application subscribes to data that is published by the LabVIEW VI and controls the robot via USB.


Come see our exciting demonstrations during the conference. You can find us at Booth 215. See you there!

A Connectivity Architecture for the Industrial Internet of Things Reply

Over time, conventional connectivity solutions can dramatically multiply development costs for your industrial Internet of Things (IoT) applications.

If it feels like you are re-inventing the wheel every time you add another application, maybe you have fallen into the trap of hanging onto the old, when you really need a new connectivity architecture – one that is ideally suited for today’s world of connected devices.

The Internet originally evolved to connect human beings, regardless of their physical location and compute environments. The current industrial IoT, in contrast, connects devices and systems. These non-human users of the industrial IoT operate in non-stop mode, and outages or failures can trigger severe consequences. Smooth operation also relies on data timeliness; the right answer delivered too late becomes the wrong answer.

The Data Distribution Service (DDS) standard evolved specifically to enable real-time, non-stop environments. In today’s industrial IoT, DDS makes it possible to connect everything, everywhere with a shared data model and open databus. Seamless data sharing can be achieved regardless of proximity, platform, language, physical network, transport protocol, and network topology.

A Generic Use Case: DDS in the Industrial IoT

More than a dozen DDS implementations have propagated the standard into hundreds of system designs in healthcare, transportation, communications, energy, industrial, defense, and other industries. Many of these domains utilize a common connectivity use case, where a user has both local and remote access to a variety of intelligent connected devices and systems.

DDS in the IIoT

Within a connected home, for example, the devices can include smart thermostats, lighting controllers, security cameras, and more. In the energy industry, the same DDS use case model lets operators oversee energy turbines at multiple locations. And in healthcare, the model can encompass smart devices at the patients’ bedsides and in the lab, with doctors and clinicians given access via the cloud or on-site LANs.

Between the devices and the cloud (WAN connections), DDS provides an ideal solution with:

  • Stateful interactions
    • Intelligent connections/disconnects, and the ability to resend only relevant data upon reconnection
    • Intelligence built into the bus, without application overhead
  • Many data-flow patterns, for meeting current and future requirements
  • Publish-subscribe architecture style that is data-driven
  • Scalability, performance, resilience, and security

Inside the endpoint devices themselves, DDS has also been applied broadly. DDS makes it possible to design smart devices that operate very reliably and meet safety and longevity requirements in industries such as healthcare and automotive. DDS has also made inroads in the cloud. Here, the standard can support diverse connectivity options, and can also promote longevity of cloud solutions.

Notice that this covers all of the connections that do not directly interface to the human beings that depend on the systems. For the user-to-cloud WAN connections traditional web technologies such as web sockets and HTTP still make sense.

For everywhere else, DDS continues to grow in popularity by saving developers time and enabling systems that can scale and accommodate smart devices and data-centric real-time environments.

Why attend RTI’s Connext Conference 2015? Reply

If the history of technology tells us one thing, it’s that standards are most effective when they are outside the control of any one organisation. Effective standards require the cooperation of strongly competing companies that work towards their mutual interest. This is because, by creating a standards framework that provides scope for innovation coupled with interoperability, more usable products are provided to the market, customers have the confidence to invest, and as a result the total available market revenues become much larger.

In his 2009 article in the RFID journal, Kevin Ashton, the man accredited with coining the phrase “the Internet of Things” stated “People have limited time, attention and accuracy—all of which means they are not very good at capturing data about things in the real world. We need to empower computers with their own means of gathering information, so they can see, hear and smell the world for themselves, in all its random glory”.

The Industrial Internet of Things is concerned with systems at the core of our daily lives that demand the highest standards of reliability, security and performance: the electricity grid, air traffic control systems and systems in space being just a few examples. Industrial sectors of the economy are responsible for two thirds of global Gross Domestic Product (GDP) and so improving the efficiency and capability of this infrastructure using distributed sensors and computing systems has the potential to revolutionise how the whole world works, serving all of us -rich or poor-, in a multitude of ways.

For the Industrial Internet of Things to be realised therefore requires companies large and small that supply and maintain industrial systems to design them work together and this in turn requires a set of standards for interoperability. In this vision of the future no system sits in its own walled garden using proprietary protocols, it must be able to interact freely with any other system, and not just ones that exist today, but those which may be designed in the future.

To meet this challenge, the Industrial Internet Consortium was formed. Today it has over 150 members from Industry, Government and Academia working on a mission to coordinate vast ecosystem initiatives to connect and integrate objects with people, processes and data using common architectures, interoperability and open standards.

RTI has made a significant investment in support for the IIC because we believe that this is the best way to allow large engineering companies to engage with technology innovators to deliver truly interoperable IIoT solutions. At our upcoming Connext Conferences in Washington and London we will be adding a focus on IIC industry standardisation alongside our traditional deep dive into Connext DDS its real-world applications.

Attending one of this year’s Connext Conferences, which will be held in Washington D.C. and London, will allow you to understand not only how to build world-class IIoT solutions, but also how your work can sit within an emerging framework for interoperability that will allow it to be applied across your industry and beyond.

Registration for these events will be open shortly – stay tuned!

The Industrial Internet Consortium takes on the Green Energy Challenge Reply

Stan Schneider, CEO of Real-Time Innovations, Industrial Internet Consortium Steering Committee Member

Today, the Industrial Internet Consortium (IIC) decided to take on the smart grid to enable large-scale efficient use of green energy. The power system is perhaps the central infrastructure of industry. Modernizing the grid is critical to building an integrated Industrial Internet of Things. Our first goal: deliver on the promise of renewable energy.

Today’s central-station-controlled power grids operate on 15-minute output update cycles; every 15 minutes, the central station estimates the power and spins up generators to meet the load. Unfortunately, renewable power sources such as solar panels or wind turbines don’t have a predictable output over that time range. Fast loads like plugging in your Tesla are also hard to predict. If the grid drops below the needed power, it can fail. So, to ensure sufficient power, grid operators spin up reserves so they can compensate for these fluctuations. That keeps the lights on, but it wastes fossil fuels and means renewables are not lowering the carbon footprint as much as they should.

However, to realize the promise of green energy at scale, we must improve control. Microgrids can be part of the answer. A microgrid puts intelligence in the field, connecting local generation sources like solar panels with controllers and storage. A microgrid can close loops in milliseconds instead of minutes. It can take advantage of practical energy storage like capacitors and batteries.

The core of a microgrid is a high-performance “field message bus.” The bus connects devices and intelligent nodes at high speeds. It can also interact with the central station and the cloud, taking advantage of both local and remote state to optimize operations.

To achieve their goal of enabling smart grids, the IIC announced its first energy-focused testbed: the Communication and Control Testbed for Microgrid Applications. IIC member organizations Real-Time Innovations (RTI), National Instruments (NI) and Cisco, are collaborating on the project, working with power utilities CPS Energy and Southern California Edison. Additional industry collaborators include Duke Energy and the power industry organization – Smart Grid Interoperability Panel (SGIP).

With this new IIC testbed, RTI, Cisco and NI are taking the grid a big step into the future. This testbed will test the contention that the DDS data-centric standard can provide the core of a microgrid-based power architecture. DDS is already operating critical grid infrastructure today, including Siemen Wind Power’s largest turbines and North America’s largest hydropower dam. This project will scale the technology down to the smallest of power systems, enabling an eventual architecture of small, efficient microgrids connected into a larger, intelligent Industrial Internet of Things whole.

We are working closely with leaders in the power industry. Southern Cal Edison has perhaps the industry’s most advanced grid simulation laboratory, with full photovoltaic, central-station, sub-station, and transmission hardware and simulators. It even features a “garage of the future” with electric cars and the required electronics. CPS Energy, the largest municipal utility in San Antonio, will do the final test phase in its real-world “Grid of the Future” neighborhood.

After a detailed analysis, Duke Energy, the largest US utility, published a distributed intelligence reference architecture for an Open Field Message Bus (OpenFMB) based on DDS last February. Also, SGIP, the leading industry grid consortium, recently launched a project to codify the data models, service requirements and standards for OpenFMB. We are working closely with these projects to ensure alignment.

Long term, the real power of the IIoT is to connect sensor to cloud, power to factory, and road to hospital. To do that, we must change core infrastructure to use generic, capable networking technology that can span industries, field and cloud. We are excited to see the IIC leading the way to a more connected, more efficient, greener world.

The Industrial Internet Consortium Turns 1 This Week! 1

I remember my daughter’s first birthday. I remember she really enjoyed her cake. And I remember spending at least 30 minutes scrubbing it out of her hair that evening.

The Industrial Internet Consortium is 1 year old! And to celebrate, they’re holding a public IIC 365 event at their quarterly meeting in Reston, Virginia on Thursday, March 26. If you are around, register and come listen. There will be a demo of the first publically announced Industrial Internet Consortium Testbed, a discussion on the World Economic Forum’s report on the potential of connected products and services, and a keynote by Dr. Joe Salvo of GE Research, one of the key instigators of the consortium. Joe Salvo alone will be worth the effort of attending.

This first publically announced testbed is actually just one of five Industrial Internet Consortium Testbeds at the moment; the others are still unannounced outside the IIC. In fact, RTI (Real-Time Innovations) is leading one of those testbeds, and we’ll be announcing it soon! At the event, you’ll get to see a demo of the Power Tools Fleet Management testbed – in other words the tracking and tracing of smart hand tools. There are actually some fascinating use cases beyond just making sure you know where all the expensive tools are in the manufacturing plant. For example, if you can track the precise location of a riveting tool and when it rivets, you can actually determine if the user missed a rivet when working on an airplane wing.

RTI was one of the first members of the Industrial Internet Consortium following its founding a year ago by GE, Intel, Cisco, IBM and AT&T. Besides having a member on the steering committee – our CEO – RTI is helping to specify the connectivity reference architecture to ensure end-to-end interoperability. We’re also helping to draft the security architecture to ensure end-to-end security for Industrial Internet of Things (IIoT) systems. We’re also active in the marketing working group, the use cases team, and the testbed working group. With over 140 companies in the consortium, and growing, I’m personally excited to see how much work is getting done and how much momentum there is behind the IIoT.

So come celebrate the Industrial Internet Consortium’s birthday in Reston. I doubt we’ll have to wash any cake out of our hair.