Well Being over Ethernet Reply

Guest Author: Andrew Patterson, Business Development Director for Mentor Graphics’ embedded software division (Thank you, Andrew!)

Mentor Embedded on the NXP Smarter World Truck 2017

Mentor Embedded on the NXP Smarter World Truck 2017

One of the larger commercial vehicles present at CES 2017 was the NXP® Smarter World Truck – an 18-wheeler parked right outside the Convention Center.  It contained over 100 demonstrations making use of NXP products showing some of the latest innovations in home-automation, medical, industrial and other fields.  Mentor Embedded, together with RTI, worked with NXP to set up a medical demonstration that showed data aggregation in real-time from medical sensors. By collecting medical data, and analyzing it in real time, either locally or in a back-office cloud, a much quicker and more accurate diagnosis of any medical condition can be possible.  Mentor Embedded’s aggregation gateway made use of the multicore NXP i.MX6, a well-established platform, running our own secure Mentor Embedded Linux®.  The technology we specifically wanted to highlight in this example was DDS (Data Distribution Service), implemented by RTI’s Connext® DDS Professional.  The DDS communication protocol, based on a physical Ethernet network, allows multiple sensor nodes to link to a hub or gateway, so it is appropriate for many medical and industrial applications where multi-node data needs to be collected securely and reliably.

Traditional patient monitoring systems have made use of client/server architectures, but these can be inflexible if reconfiguration changes are needed, and they don’t necessarily scale to a large number of clients in a large-scale medical or industrial installation. DDS uses a “publisher” and “subscriber” concept – it is easy to add new publishers and subscribers to the network without any other architecture changes, so the system is scalable.


In the publish-subscribe model there is no central data server – data flows directly from the patient monitor source to the gateway destination.  In our demo medical system, the data sources are individual sensors that put data onto the Ethernet network when the new readings are available.  Data is tagged for reading and accessed by any registered subscriber.  Once received by the subscriber gateway, the data can be uploaded to a cloud resource for further analysis and comparisons made with historical readings. Further trend analysis can be made over time.

The process for adding a new node to a publish-subscribe network is straightforward. A new data element announces itself to the network when it attaches, optionally describing the types and formats of the data it provides. Subscribers then identify themselves to the data source to complete the system reconfiguration.

Mentor Embedded and RTI medical applications demo where multi-node data needs to be collected securely and reliably

Mentor Embedded and RTI medical applications demo where multi-node data needs to be collected securely and reliably

DDS provides a range of communication data services to support a variety of application needs, ranging from guaranteed command and control, to real-time data transmission. For example, if it is required to send a “halt” command to a specific node, there is a data service type that guarantees error-free delivery, so sensor data transmission stops immediately. There are also time-sensitive modes, useful when there is time-sensitive data, which require minimum network latency.  Less time-critical data can make use of a “best effort” service, where transmission is scheduled as a lower priority than the time-sensitive communication.

Our demonstration setup is shown in the picture on the left in the NXP Smarter World Truck 2017. The NXP i.MX6 quad core system was linked to a 10” touch-screen display, showing patient graphs.  The Mentor Embedded Linux operating system included the RTI Connext DDS protocol stack, the necessary drivers for high-performance graphics, and the Ethernet network connections. Other options include a fastboot capability and wireless communication links for cloud-connectivity.  For more information please visit Mentor Embedded Linux.

To see when the NXP Smarter World Truck is coming near you, visit the schedule at iot.nxp.com/americas/schedule – it is being updated frequently, so keep a watch on it!

Linux is the registered trademark of Linus Torvalds in the U.S. and other countries.

2nd Version of the Industrial Internet Reference Architecture is Out with Layered Databus Reply


A year and a half ago the IIC released the first version of the Industrial Internet Reference Architecture (IIRA) – now the second version (v1.8) is out. It includes tweaks, updates and improvements, the most important or interesting of which is a new Layered Databus Architecture Pattern. RTI contributed this new architecture pattern in the Implementation Viewpoint of the IIRA because we’ve seen it deployed by hundreds of organizations that use DDS. Now it’s one of the 3 common implementation patterns called out by the new version of the IIRA.

So, what is a databus? According to the IIC’s Vocabulary document, “a databus is a data-centric information-sharing technology that implements a virtual, global data space, where applications read and update data via a publish-subscribe communications mechanism. Note to entry: key characteristics of a databus are (a) the applications directly interface with the operational data, (b) the databus implementation interprets and selectively filters the data, and (c) the databus implementation imposes rules and manages Quality of Service (QoS) parameters, such as rate, reliability and security of data flow.”

For those who know the DDS standard, this should sound familiar. You can implement a databus with a lower level protocol like MQTT, but DDS provides all the higher-level QoS, data handling, and security mechanisms you will need for a full featured databus.

As we look across the hundreds of IIoT systems DDS users have developed, what emerges is a common architecture pattern with multiple databuses layered by communication QoS and data model needs. As we see in the figure below, we’ll usually see databuses implemented at the edge in the smart machines or lowest level subsystems like a turbine, a car, an oil rig or a hospital room. Then above those, we’ll see one or more databuses that integrate these smart machines or subsystems, facilitating data communications between them and with the higher level control center or backend systems. The backend or control center layer might be the highest layer databus we see in the system, but there can be more than these three layers. It’s in the control center (which could be the cloud) layer that we see the data historians, user interfaces, high-level analytics and other top-level applications. From this layer, it’s straightforward to zero in on a particular data publication at any layer of the system as needed. It’s from this highest layer that we usually see integration with business and IT systems.


The Layered Databus Architecture Pattern: one of three implementation patterns in the newly released Industrial Internet Reference Architecture v1.8.

Why use a layered databus architecture? As the new IIRA says, you get these benefits:

  • Fast device-to-device integration – with delivery times in milliseconds or microseconds
  • Automatic data and application discovery – within and between databuses
  • Scalable integration – comprising hundreds of thousands of machines, sensors and actuators
  • Natural redundancy – allowing extreme availability and resilience
  • Hierarchical subsystem isolation – enabling development of complex system designs

If you want to dig into the databus concept, especially as it compares with a database (similar data-centric patterns for integrating distributed systems, but different in the way they integrate via data), take a look at this earlier blog post on databus versus database.

In addition to the new IIRA release, the IIC is getting ready to release an important document on the Connectivity Framework for its reference architecture. Look for much more detail on this document that sets out core connectivity standards for the Industrial Internet.

RTI Perftest 2.0 is Now Available! Reply


I am proud to announce the release of RTI Perftest 2.0! We developed it to test the performance of RTI Connext DDS 5.2.x. This release is packed with tons of important changes and features. Let’s take a look at the most notable ones below.

Now on Github:


We decided to bump up the way we maintain and distribute the code. Our RTI Perftest code can now easily be located in a public repository on Github (Link). We also intend to update RTI Perftest code not just from release to release, but every time a feature or a bug fix is completed. We encourage you all to contribute with any ideas, changes or fixes by forking from our project and then doing a pull request with the changes.

New Versioning Schema

You might have noticed already that we moved from using the RTI Connext DDS versioning schema (5.2.0, 5.2.3, etc) to a new one: RTI Perftest 2.0. The reason for this change is to de-couple the RTI Perftest releases from the RTI Connext DDS ones. Our goal is to make sure that every new release of RTI Connext DDS will be compatible with the latest version of RTI Perftest.

New Directory Structure and a Better Compilation System

For this release, we wanted to focus on organizing and simplifying our code and its compilation. The code is conveniently arranged with fewer folders and more descriptive names. Instead of maintaining a huge number of makefiles and visual studio solutions, we leveraged two build scripts (one for Unix systems and another for Windows). This will utilize RTI Connext DDS Code generator (rtiddsgen) and use the specific makefiles/solutions for your architecture. Side effect? We can automatically support every architecture for which rtiddsgen can generate a makefile or a solution.

Easy Access to Documentation

We have rebuilt the documentation in markdown and will automatically generate html documents for every new release. And we will always keep it online and updated: Link.

Dynamic Data and UDPv6 Support

Two additional and very important features for RTI Perftest that allows you to test a wide range of new scenarios. For full details, visit the Release Notes where you will also find more about new features and bugfixes.

Compile and Execute in an Embedded Platform with Ease

We designed our build system so now cross-compiling from linux is much easier. There is no need to create specific makefiles for your architecture and hardcode tons of paths.