ISO 26262 Certification for Software Components Reply

Guest author: Joe Wlad, Vice President, Business Development, Verocel, Inc. 


The automotive industry has adopted ISO 26262 as its functional safety standard for electronic systems. The current version of ISO 26262 was published in 2011, with a second edition scheduled for release in 2018. The increased use of software in automotive systems such as driver assist, brake control and engine and systems management has placed a greater scrutiny on ensuring the software is safe. Modern vehicles now contain millions of lines of software and software quality is more important than ever. While automotive designers and suppliers have 5 years’ experience using ISO 26262, the bar for software compliance is now higher due to increased complexity, integration and automation. Moreover, one can expect regulatory oversight to increase in the future due to changing policies. In September 2016, the U.S. DOT issued a new federal policy for safe testing and deployment of automated vehicles. This new policy seeks to strike a fair balance between innovation and regulatory oversight but will require additional effort from vehicle makers and suppliers who wish to use forms of automation in their future designs.


Historically, all automotive companies and suppliers practiced a form of “self-certification” regarding their systems, hardware and software. To date, there is no pre-market approval process and no government regulator in the loop. Manufacturers do their own due diligence and any government oversight of safety design, development and production comes into play only after vehicles go into production. Even though a pre-market approval process for road vehicles would be impractical even for autonomous features, designers will have to place additional emphasis on software design and verification practices in the near future. Fortunately, ISO 26262 addresses the key requirements for software development and design and software suppliers like RTI are prepared to assist designers in ensuring compliance with ISO 26262 software requirements.

ISO 26262 covers functional safety at the system, hardware and software levels. To be considered fully compliant with ISO 26262, all areas must be addressed at once meaning that the software has to be integrated onto a given hardware platform and within a given system before it is approved. This poses a dilemma for suppliers who wish to use COTS software such as an operating system or communication layer because it places an additional certification burden on the supplier to represent software they may not have designed themselves. Companies like RTI and Verocel have addressed this problem by providing both certification evidence and a framework to use that evidence in any system design and achieve ISO 26262 compliance at ASIL-D. The details of this approach are documented in a whitepaper called ISO 26262 Compliance Using Approved Software Components for Road Vehicles which can be downloaded at both the RTI and Verocel websites.


The whitepaper provides a complete background on ISO 26262 processes and what parts of the standard would apply to COTS software components. It also provides a summary of key characteristics of COTS software that can be used in road vehicle designs as well as documentation and evidence to assist the integrator in achieving ISO 26262 compliance. RTI Connext DDS Cert supports the DDS (Data Distribution Service) family of standards and is a certifiable middleware available with a complete, commercially supported certification package to support ISO 26262 certification, including ASIL-D. Connext DDS Cert provides an architecture and hardware-independent layer of software that can be used on virtually any system design. It also comes with the certification evidence that supports ISO 26262, sections 2, 6 and 8 as well as additional guidance and information that helps designers integrate Connext DDS and retain certification credit in their system.

Automotive designers and suppliers need to prepare for a future where increased regulatory compliance for software will be a norm. The days of complete self-certification autonomy are coming to an end and suppliers will need to rely on an entire software ecosystem of suppliers who can meet the current and future ISO 26262 requirements head-on. RTI and Verocel have broad experience in delivering certified software to customers in many industries and we are prepared to assist you.

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.


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
RUN unzip
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
RUN unzip
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 and

FROM dds-base:latest                                    (

# 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

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

# 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", ""] 

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

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

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

The docker build using the 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 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 .

$ 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! 

DDS Proof Points for Autonomous Cars Reply

autonomous car design rti connext dds

While implementation details for autonomous cars are still tightly guarded design secrets, deployment examples in adjacent markets provide a wealth of information about DDS and its ability to solve the most challenging connectivity problems.

The following use cases have one or more connectivity issues in common with autonomous cars. Autonomous car requirements span three main areas: performance, safety, and integration. Systems must ensure performance to successfully connect components, optimize safety at every level of a fully autonomous system, and make it easier to reliably integrate complex software from diverse components.

Performance: Revised Approach to Automotive System Testing

Familiar names such as Audi and Volkswagen are among the carmakers that have already introduced RTI Connext DDS to enable high-performance connectivity for testing and enhancing today’s smart cars.

  • Audi replaced a proprietary fiber network and test rig with a DDS databus, for a more flexible way to connect multiple simulation vendors’ systems. RTI middleware enables a modular test environment with the speed to handle data coming from all of the electronic systems in a vehicle during simulated. Additional details can be found here: A New Architecture for Hardware-in-the-Loop Test via ATZ Elektronik
  • At Volkswagen, autonomous vehicle algorithms are part of the company’s efforts to evolve driver assistance and integrated safety. The system combines radars, laser range finders, and video to assist safe operation. VW uses RTI Connext DDS to help drivers avoid obstacles, detect lane departures, track eye activity, and safely negotiate turns. The DDS protocol connects all of the required components to create a single, intelligent machine with driver-assistance features and integrated. Read more…
  • Volkswagen has also used DDS technology in an electric vehicle capable of autonomously driving to and from a recharging station after dropping off

Resilience and Safety: Unmanned Aircraft

Engineers of aeronautic and defense systems have long relied on RTI’s award-winning infrastructure technology to develop unmanned aircraft as well as unmanned vehicles for deployments on land and under water.

DDS aligns with many open architecture initiatives including the Future Airborne Capability Environment, UAS Control Segment Architecture, and Open Mission Systems. Connext DDS Cert also helps developers of Unmanned Air Systems prepare for integration into the National Air Space. Connext DDS Cert accommodates communication requirements while minimizing the amount of custom code that must be certified.

Stringent safety requirements within this industry segment closely resemble automotive compliance specifications. The certification process depends on close collaboration between technology vendors and solution designers – and in the case of autonomous cars, RTI has already established working relationships with vehicle manufacturers. These joint efforts and investments will ensure the required certifications and safety levels the automotive industry requires.

System Integration: Healthcare

Advanced device connectivity is changing medical practices, lowering costs, and improving patient outcomes. Current medical applications of RTI Connext DDS Autonomous Cars White PaperDDS demonstrate how it can help integrate complex distributed subsystems and devices in a manner that ensures the required performance. For example, RTI Connext DDS provides precise, distributed control for the subsystems within leading-edge computed tomography (CT) imagers. In hospital infrastructures, RTI’s DDS implementations are also in use to connect a myriad of technologies for patient monitoring and diagnostics that power modern hospital equipment.

If you’re interested in discovering how you can use Connext DDS in autonomous car design to gain an undeniable competitive edge, download our latest white paper (here).