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.

medical-dds-on-ethernet-protocol-520x273

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.

How to Integrate RTI Connext DDS Micro with Container-Based Applications [tutorial] 2

integration of container based apps with connext dds

Container-based microservices are all the rage as software architects and engineers work to bring the flexibility and scalability of the cloud to the edge. To support real-time communication between those microservices with a guaranteed Quality of Service (QoS), DDS makes the perfect companion. This post covers the steps necessary to integrate RTI Connext DDS Micro with container-based applications. The steps required and benefits of the technology will be described in the context of a simple publisher/subscriber example.

ConnextDDSMicroContainer

Before we get started a little background is helpful. At an abstract level, containers are used to run individual, isolated applications on your machine. Each container provides operating-system level capabilities making it possible to run isolated Linux systems on one host.  Containers serve as a lightweight alternative to full machine virtualization, which requires use of hypervisors to manage multiple operating systems. Docker is the world’s leading software containerization platform. As such, it is often used interchangeably when discussing container technology even though there are other alternatives.  Please ensure you have Docker installed and functioning correctly on your machine by following the getting started documentation.

One of the first considerations when creating an image is what base image to build on.  For our purposes, we use Alpine Linux as the base image for the container. Alpine is a very lightweight, thin Linux weighing in at only 5 MB. Because it is so minimalistic, containers using it have faster build times while still including the most necessary and important functions. This makes Alpine a good option to use with micro-DDS. RTI Connext DDS Micro comes with a large number of pre-built and tested libraries for various operating systems.  However, the binaries aren’t available for this configuration, but luckily, Connext DDS Micro is available in source code form and can be built easily.  So let’s get started with that task.

Building the Example

Our first task is to build the Connext DDS Micro libraries and create a build image or build-pack.  The goal of the build image is to assist in building the runtime image from source code, 3rd party libraries, etc.  Remember that images are the main component in building containers, and when working with Docker the blueprint is contained in a Dockerfile.  Here is the Dockerfile for the build image or build-pack:

FROM alpine:3.3

# Install Alpine packages to support build of RTI Micro DDS
RUN apk add --update alpine-sdk bash cmake linux-headers openjdk7-jre && rm -rf /var/cache/apk/*

# Extract RTI Micro DDS host tools and point to Alpine JRE for build
COPY RTI_Connext_Micro_Host-2.4.8.zip RTI_Connext_Micro_Host-2.4.8.zip
RUN unzip RTI_Connext_Micro_Host-2.4.8.zip
RUN rm -rf /rti_connext_micro.2.4.8/rtiddsgen/jre/i86Linux
RUN ln -s /usr/lib/jvm/default-jvm/jre /rti_connext_micro.2.4.8/rtiddsgen/jre/i86Linux

# Extract RTI Micro DDS source and patch for build
COPY RTI_Connext_Micro-2.4.8-source.zip RTI_Connext_Micro-2.4.8-source.zip
RUN unzip RTI_Connext_Micro-2.4.8-source.zip
COPY  patch/posixMutex.c rti_connext_micro.2.4.8/source/unix/src/osapi/posix/

# Build RTI Micro DDS
RUN mkdir /build \
    && cd /build \
    && cmake -DRTIMICRO_BUILD_LANG:STRING=C++/rti_connext_micro.2.4.8/source/unix \
    && make \
    && cp -R /build/lib /rti_connext_micro.2.4.8 \
    && rm -rf /build 

It isn’t that different than you’d expect to see in a standard build script.   The first line identifies the base image to be used.   As previously mentioned we’ll be using Alpine version 3.3 available from the public Docker registry.  Next, we install some build dependencies using apk (Alpine package manager).  After that we unzip and patch the source and use traditional cmake and make commands to build the C++ libraries.    To build an image from this Dockerfile we change to the directory containing this file and execute the build command.

$ docker build –t dds-base .

The –t command tags the image with a human-friendly string versus a randomly generated one for future use.    So the build image or build-pack has been created. Let’s use this image to create the publisher and subscriber images.  

The creation of the publisher and subscriber are similar and accomplished in two steps.  The first step uses the previously created build image or build-pack to compile the executable and the second takes the generated executable and packages it in a runtime image.   This two-phased approach minimizes the size of the container since the build tools and intermediate artifacts are discarded when the runtime image is created.  The two Dockerfiles used in creating the images are intuitively called Dockerfile.build and Dockerfile.run.

FROM dds-base:latest                                    (Dockerfile.build)

# Add publisher source code for build
COPY /src /src

# Compile sources to executable
RUN set -ex \
    && cd /src \
    && /rti_connext_micro.2.4.8/rtiddsgen/scripts/rtiddsgen -replace -language microC++ HelloWorld.idl \
    && g++ -Wall -DRTI_UNIX -DRTI_LINUX -DRTI_POSIX_THREADS -I. -I/rti_connext_micro.2.4.8/include -I/rti_connext_micro.2.4.8/include/rti_me *.cxx -L/rti_connext_micro.2.4.8/lib/i86Linux2.6gcc4.4.5/ -o HelloWorld_publisher -L/rti_connext_micro.2.4.8/lib/i86Linux2.6gcc4.4.5/ -lrti_me_cppz -lrti_me_rhsmz -lrti_me_whsmz -lrti_me_discdpdez -lrti_me_discdpdez -lrti_mez -ldl -lpthread -lrt \
    && chmod +x HelloWorld_publisher \
    && mv HelloWorld_publisher /bin

# copy the runtime dockerfile into the context
COPY Dockerfile.run Dockerfile

#export the dockerfile and executable as a tar stream
CMD tar -cf - Dockerfile /bin 
FROM alpine:3.3                                          (Dockerfile.run)

# Include Standard C++ Library
RUN apk add --update libstdc++ && rm -rf /var/cache/apk/*

# Add service and application
COPY /bin/HelloWorld_publisher /bin/HelloWorld_publisher
RUN chmod a+x /bin/HelloWorld_publisher

# Start publisher using multicast for discovery
CMD ["/bin/HelloWorld_publisher", "-peer", "239.255.0.1"] 

The two steps are accomplished through a series of docker build and run commands.  

$ docker build --force-rm -t dds-builder -f Dockerfile.build .

$ docker run --rm dds-builder | docker build --force-rm -t dds-publisher - ; 

The docker build using the Dockerfile.build file copies the source code and builds the binary.  The run command creates a container from that built image.  When that container executes it packages up the available binary into a tar stream and setups the resources for the runtime image build.   The last docker build uses the Dockerfile.run file and the tar stream piped in to copy the files to the appropriate location after installing C++ standard library runtime. 

The subscriber follows the exact same approach.  Change into the subscriber directory and repeat the previous docker build and run commands using the subscriber rather than the publisher name when tagging the image.

$ docker build --force-rm -t dds-builder -f Dockerfile.build .

$ docker run --rm dds-builder | docker build --force-rm -t dds-subscriber - ; 

The images have been built but before proceeding, we should verify that by executing the docker images command.  This command lists all the images available in your local registry.  You should see the two images we created in the previous steps.

$ docker images | grep dds
REPOSITORY        TAG                 IMAGE ID            CREATED             SIZE 
dds-subscriber    latest              0442ffc6ca02        2 minutes ago      8.098 MB 
dds-publisher     latest              15fa3c2ed441        4 minutes ago      8.084 MB

Running the Example

Now that we built the images we should take them for a test drive and ensure the example runs successfully.  Open two terminal windows.  We’ll use one for the publisher and the other for the subscriber.  In one of the windows start the publisher using the docker run command.

$ docker run -t dds-publisher

If everything is successful you should see the “Hello World” text followed by a number that is incremented after every message is published.

Hello World (0) 
Hello World (1) 
Hello World (2) 
Hello World (3) 
Hello World (4) 
Hello World (5) 
Hello World (6) 
… 

With the publisher successfully running we can start the subscriber and see if the DDS messages are being received across the two containers over the Docker bridge network.

$ docker run -d -t dds-subscriber

The output should look similar to this, proving the subscriber is working:

Sample received     msg: Hello World (9)  
Sample received     msg: Hello World (10)  
Sample received     msg: Hello World (11)  
Sample received     msg: Hello World (12)  
Sample received     msg: Hello World (13)  
Sample received     msg: Hello World (14) 
… 

The number starts with the most recent published because the QoS didn’t have any history settings.  Both of these containers will continue to run until they are manually stopped or the container engine is brought down.  After the learning curve of containers is overcome the rest is just DDS the way you’ve (hopefully) done in the past.

Next Steps

Linux containers, especially Docker, are providing improvements across the DevOps cycle.   They provide a convenient packaging mechanism and promote a modular, microservice based architecture.  Using DDS as the data bus between container-based microservices provides an asynchronous publish/subscribe data bus for these services to communicate when traditional synchronous REST-based approaches are insufficient.   Together they make a solid choice for the Industrial Internet and Internet of Things software architecture.   Take the next step and start using RTI Connext DDS Micro with your container-based architecture today.

Special thanks to Katelyn Schoedl, Research Intern, GE Global Research and Joel Markham, Senior Research Engineer, GE Global Research for authoring this guest blog post – THANK YOU! 

Unprecedented Achievements in Connected Systems: How 3 companies used DDS to achieve inspired results. Reply

inspiredResults.jpg

As cheesy as it may sound, it’s the truth: our customers build things that are downright inspiring. They tackle the hard problems, seemingly preferring to run head on into a challenge as opposed to shying away from it. As a result, many of them have built systems and architectures that are saving lives, improving the quality of our experiences with technology, and pushing the boundaries of what we think is possible.

So who are these customers? What are they doing? Today I’m sharing the stories of three companies whose results are inspired, to say the least. Two of these applications are in the robotics domain, the other is in healthcare, and all three used Connext DDS.

Unprecedented Achievements in Connected Systems: How 3 companies used DDS to achieve inspired results.

1) ESA Telerobotics and Haptics Laboratory

I remember this like it was yesterday: a photo of our CTO, Gerardo, taken at a customer site visit, popped up on my screen. He visits many customers, but this wasn’t just any picture. This was a picture of him rocking a … robotic arm? No, an exoskeleton. I was jealous, to say the least.

This is the stuff my sci-fi-nerd-EE dreams are made of. Do you know the types of challenges they would have to overcome to achieve their goals? Here are two of their challenges: datalinks and latency. After viewing Andre Schiele’s TED Talk (go to 2h19min), my mind was buzzing with a list of possible applications and benefits that could be realized because of this technology. Think, remote surgery (over very long distances) and enabling exploration and scientific research in new places that are too dangerous for humans.

Since May 2014, this team has made amazing progress with their work. In December of that year, they performed the first ever robotic experiment with force-feedback in space (details), and since then they’ve shown no signs of slowing down.

2) GE Healthcare

Connected medical devices save lives, and GE Healthcare is taking this to the next level by using Connext DDS to standardize communications for new generations of many products. A connected patient care ecosystem can not only allow for more efficient machine operation, it can also decrease the configuration costs. What do these things mean and how do patients benefit from such a system? Here are some examples:

  1. By networking the many types of devices in a hospital room, alarms can become smart, only sounding when multiple devices indicate errant physiological parameters.
  2. By connecting measurements to treatment, smart drug delivery systems can react to patient conditions quickly and reliably.
  3. By tracking patients around the hospital and connecting them to cloud resources, efficiency of care can be dramatically improved.

“GE Healthcare chose the DDS standard because it can handle many classes of intelligent machines,” said J Gustavo Perez, General Manager for MI&CT Engineering at GE. “RTI Connext DDS satisfies the demanding requirements of our devices and supports standardization on a single communications platform across product lines.”

To learn more about RTI, GE Healthcare, and how they’re enabling smarter systems of connected medical devices in hospitals as well as fast integration and connectivity of large medical instruments, be sure to watch this free webinar: The Inside Story: GE Healthcare’s Industrial Internet of Things (IoT) Architecture

3) Institute of Robotics and Mechatronics, DLR 

At last year’s London Connext Conference 2015, one of our keynote presentations was delivered by Sergey Tarassenko, a research assistant at the Institute of Robotics and Mechatronics, DLR. His presentation, DLR MiroSurge ‐ Telemanipulation in Minimally Invasive Surgery, combines the best of robotics and healthcare.

Minimally Invasive Surgery (MIS) challenges the surgeon’s skills due to their separation from the operation area, which can only be reached by long laparoscopic instruments. To overcome the drawbacks of conventional MIS, Sergey and his team are working on a research system for telerobotic endoscopic surgery: MiroSurge.

In the DLR telesurgery scenario, the MiroSurge system includes:

  1. A master console with a 3D-display and
  2. Two haptic devices to control
  3. Three MIRO robot arms

Connext DDS provides the communications infrastructure between robots, controllers and user interfaces, facilitating synchronization and coordination between them. To learn more about this, head on over to SlideShare and view the slides from the event (below).