greek64/rtps-fpga
2
1
Fork 0
Code Issues Pull Requests Releases Wiki Activity
2df7f10832
rtps-fpga/Thesis/MSc.tex

5377 lines
383 KiB
TeX
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

% Copyright (C) 2014-2020 by Thomas Auzinger <thomas@auzinger.name>
\documentclass[a4paper,oneside]{vutinfth}
% Load packages to allow in- and output of non-ASCII characters.
\usepackage{lmodern} % Use an extension of the original Computer Modern font to minimize the use of bitmapped letters.
\usepackage[T1]{fontenc} % Determines font encoding of the output. Font packages have to be included before this line.
\usepackage[utf8]{inputenc} % Determines encoding of the input. All input files have to use UTF8 encoding.
% Extended LaTeX functionality is enables by including packages with \usepackage{...}.
\usepackage{array}
\usepackage{amsmath} % Extended typesetting of mathematical expression.
\usepackage{amssymb} % Provides a multitude of mathematical symbols.
\usepackage{mathtools} % Further extensions of mathematical typesetting.
\usepackage{microtype} % Small-scale typographic enhancements.
\usepackage[inline]{enumitem} % User control over the layout of lists (itemize, enumerate, description).
\usepackage{multirow} % Allows table elements to span several rows.
\usepackage{hhline} % Don't you hate it when a double \hline interrupts the vertical lines in a table? Hate no more!
\usepackage{booktabs} % Improves the typesettings of tables.
\usepackage{subcaption} % Allows the use of subfigures and enables their referencing.
\usepackage[ruled,linesnumbered,algochapter]{algorithm2e} % Enables the writing of pseudo code.
\usepackage[usenames,dvipsnames,table]{xcolor} % Allows the definition and use of colors. This package has to be included before tikz.
\usepackage{nag} % Issues warnings when best practices in writing LaTeX documents are violated.
\usepackage{todonotes} % Provides tooltip-like todo notes.
\usepackage{underscore} % Prevents that GODDAMN Underscore escaping need.
\usepackage{layouts}
\usepackage{tikz,environ}
\usepackage{listings} % For code listings
\usepackage{tikz-timing}
\usepackage{caption}
\usepackage{placeins} % For the amazing \FloatBarrier Command!
\usepackage{tablefootnote} % Allows footnotes inside \table environments
\usepackage[normalem]{ulem} % For strikethrough text
\usepackage[backend=biber,style=numeric,sorting=none]{biblatex} % Bibliography
\addbibresource{Ref.bib}
\usepackage{hyperref} % Enables cross linking in the electronic document version. This package has to be included second to last.
\usepackage[acronym]{glossaries} % Enables the generation of glossaries and lists for acronyms. This package has to be included last.
%***************SETTINGS***************
\setpnumwidth{2.5em} % Avoid overfull hboxes in the table of contents (see memoir manual).
\setsecnumdepth{subparagraph} % We, I mean I, want to have numbering until subparagraphs
\settocdepth{subsubsection} % Ditto, but until subsubsections.
\nonzeroparskip % Create space between paragraphs (optional).
\setlength{\parindent}{0pt} % Remove paragraph identation (optional).
\interfootnotelinepenalty=10000 % Prevent footnote breaking into multiple pages
%**************************************
%\makeindex % Use an optional index.
%\makeglossaries % Use an optional glossary.
%\glstocfalse % Remove the glossaries from the table of contents.
\GlsDeclareNoHyperList{acronym} % Disable Hyperlink for acronyms
\DeclareCaptionType{timingdiag}[Timing Diagram][List of Timing Diagrams]
%***************VUTINFTH SETTINGS***************
% Define convenience functions to use the author name and the thesis title in the PDF document properties.
\newcommand{\authorname}{Ioannis Daktylidis} % The author name without titles.
\newcommand{\thesistitle}{A Generic Infrastructure for Facilitating Hardware Acceleration in the Robotic Operating System (ROS 2)} % The title of the thesis. The English version should be used, if it exists.
% Set persons with 4 arguments:
% {title before name}{name}{title after name}{gender}
% where both titles are optional (i.e. can be given as empty brackets {}).
\setauthor{}{\authorname}{}{male}
\setadvisor{Prof. Dipl.-Ing. Dr.Tech.}{Andreas Steininger}{}{male}
% For bachelor and master theses:
%\setfirstassistant{Pretitle}{Forename Surname}{Posttitle}{male}
%\setsecondassistant{Pretitle}{Forename Surname}{Posttitle}{male}
%\setthirdassistant{Pretitle}{Forename Surname}{Posttitle}{male}
% For dissertations:
%\setfirstreviewer{Pretitle}{Forename Surname}{Posttitle}{male}
%\setsecondreviewer{Pretitle}{Forename Surname}{Posttitle}{male}
% For dissertations at the PhD School and optionally for dissertations:
%\setsecondadvisor{Pretitle}{Forename Surname}{Posttitle}{male} % Comment to remove.
% Required data.
\setregnumber{01128193}
\setdate{20}{08}{2023} % Set date with 3 arguments: {day}{month}{year}.
\settitle{\thesistitle}{Eine Generische Infrastruktur für die Ankopplung von Hardwarebeschleunigern an das Robotic Operating System\\ (ROS 2)} % Sets English and German version of the title (both can be English or German). If your title contains commas, enclose it with additional curvy brackets (i.e., {{your title}}) or define it as a macro as done with \thesistitle.
\setsubtitle{}{} % Sets English and German version of the subtitle (both can be English or German).
% Select the thesis type: bachelor / master / doctor / phd-school.
% Bachelor:
%\setthesis{bachelor}
%
% Master:
\setthesis{master}
\setmasterdegree{dipl.} % dipl. / rer.nat. / rer.soc.oec. / master
%
% Doctor:
%\setthesis{doctor}
%\setdoctordegree{rer.soc.oec.}% rer.nat. / techn. / rer.soc.oec.
%
% Doctor at the PhD School
%\setthesis{phd-school} % Deactivate non-English title pages (see below)
% For bachelor and master:
\setcurriculum{Embedded Systems}{Embedded Systems} % Sets the English and German name of the curriculum.
% For dissertations at the PhD School:
\setfirstreviewerdata{Affiliation, Country}
\setsecondreviewerdata{Affiliation, Country}
%***********************************************
% Set PDF document properties
\hypersetup{
pdfpagelayout = OneColumn, % How the document is shown in PDF viewers (optional).
pdfauthor = {\authorname}, % The author's name in the document properties (optional).
pdftitle = {\thesistitle}, % The document's title in the document properties (optional).
pdfsubject = {\thesistitle}, % The document's subject in the document properties (optional).
pdfkeywords = {ROS, ROS2, FPGA, HDL, DDS, RTPS, VHDL}, % The document's keywords in the document properties (optional).
pdftoolbar = true, % show Acrobat’s toolbar?
pdfmenubar = true, % show Acrobat’s menu?
pdffitwindow = false, % window fit to page when opened
pdfstartview = {FitH}, % fits the width of the page to the window
pdfnewwindow = true, % links in new window
bookmarks = true, % show bookmarks bar?
unicode = false, % non-Latin characters in Acrobat’s bookmarks
colorlinks = true, % false: boxed links; true: colored links
linkcolor = red, % color of internal links (change box color with linkbordercolor)
linkbordercolor = {Melon}, % The color of the borders of boxes around crosslinks (optional).
citecolor = green, % color of links to bibliography
filecolor = magenta, % color of file links
urlcolor = cyan % color of external links
}
%******************COMMANDS******************
%Custom hyperref command
\newcommand{\cref}[2]{\hyperref[#2]{#1 \ref{#2}}}
%Redefine the section commands with FloatBarriers to prevent Floats from appearing
%in the wrong sections
\let\Oldsection\section
\renewcommand{\section}{\FloatBarrier\Oldsection}
\let\Oldsubsection\subsection
\renewcommand{\subsection}{\FloatBarrier\Oldsubsection}
\let\Oldsubsubsection\subsubsection
\renewcommand{\subsubsection}{\FloatBarrier\Oldsubsubsection}
%Define Commands to disable TIKZ generation to speed up compilation
\newif\ifhidetikz
\hidetikzfalse
%\hidetikztrue % <---- uncomment this line to speed up compilation
\newcounter{tikzfigcntr}
\ifhidetikz\RenewEnviron{tikzpicture}[1][]{%
\par% New paragraph
\stepcounter{tikzfigcntr}% Step tikzfigcntr counter
This is \texttt{tikzpicture}~\thetikzfigcntr% Place appropriate text
\par% New paragraph
}
\fi
%********************************************
%******************LISTS SETTINGS******************
\setlist[description]{style=nextline}
%\newlist{citemize}{itemize}{4}
%\setlist[itemize]{
% leftmargin=50pt,
% labelwidth=40pt,
% itemindent=20pt,
% rightmargin=-20pt,
% label=\bfseries
%}
%************************************************
\input{Glossary.tex}
\begin{document}
\frontmatter % Switches to roman numbering.
% The structure of the thesis has to conform to the guidelines at
% https://informatics.tuwien.ac.at/study-services
\addtitlepage{naustrian} % German title page (not for dissertations at the PhD School).
\addtitlepage{english} % English title page.
\addstatementpage
%\begin{danksagung*}
%\todo{Ihr Text hier.}
%\end{danksagung*}
%\begin{acknowledgements*}
%\todo{Enter your text here.}
%\end{acknowledgements*}
%\begin{kurzfassung}
%\todo{Ihr Text hier.}
%\end{kurzfassung}
\begin{abstract}
Since the release of the popular open-source software framework \acrshort{ROS} in 2007 a lot as changed in the robotics industry, which necessitated a complete re-work of the framework, released under the name \acrshort{ROS} 2 in 2017.
At the same time the ever increasing demand for performance and power efficiency in robotics has pushed research in integrating hardware-acceleration (e.g. via \acrshortpl{FPGA}) into \acrshort{ROS} systems.
The relative simple communication schema of \acrshort{ROS} 1 has resulted in many papers and solutions to be presented over the years.
On the other hand the more complicated communication schema used in \acrshort{ROS} 2, which is based on the on the \acrshort{RTPS}/\acrshort{DDS} specifications, is usually tackled by using programmable \acrshortpl{SOC}.
The programmable \acrshort{SOC} allows the \acrshort{ROS} framework to run on a minimal \acrshort{OS} on a \acrshort{CPU}, while the actual acceleration happens selectively on the interconnected \acrshort{FPGA}.
With the official \acrshort{ROS} 1 distribution released on May of 2020 also being the last, the need for a more complete \acrshort{ROS} 2 integration in \acrshortpl{FPGA} is higher than ever.
This thesis presents complete open-source \acrshort{HDL} implementations for both \acrshort{RTPS} and \acrshort{DDS} specifications, as well as a \acrshort{ROS} wrapper that allow a \acrshort{HW}-only \acrshort{ROS} 2 system to reside entirely in the \acrshort{FPGA}.
Comparison with a \acrshort{ROS} 2 system residing on the \acrshort{CPU} of a programmable \acrshort{SOC} show up to 3x performance improvement.
\end{abstract}
% Select the language of the thesis, e.g., english or naustrian.
\selectlanguage{english}
% Add a table of contents (toc).
\tableofcontents % Starred version, i.e., \tableofcontents*, removes the self-entry.
% Switch to arabic numbering and start the enumeration of chapters in the table of content.
\mainmatter
%*******************************************CHAPTER********************************************
\chapter{Introduction}
\label{ch:introduction}
Robots are getting more and more aware of their surroundings, which allows them to be used in new domains, but at the same time increases their computational demands.
Since most robots are usually battery operated, roboticists have an energy budget that they have to design with.
This pushes the demand for computational efficiency.
The options available to roboticists are \glspl{CPU}, \glspl{GPU}, \glspl{FPGA}, and \glspl{ASIC}.\\
From those, \glspl{CPU} provide the most general support and are also the most wide-spread used option, but lose in comparison to the other option both in terms of performance and energy efficiency.\\
\glspl{GPU} on the other hand eclipse the rest in terms of performance\footnote{This depends heavily on the applied workload.}, but have the worst energy efficiency.\\
\glspl{ASIC} provide workload specific hardware, that give both the best performance and energy efficiency out of all options, but are cost inefficient and lack adaptability, which is important for the fast changing nature of robots.\\
\glspl{FPGA} provide a middle ground, where one can describe a hardware architecture with a \gls{HDL} and run it on top of a special hardware platform.
This option satisfies all mentioned aspects (good performance, high energy efficiency, low cost, high adaptability) and seems like the perfect option for roboticists.
Unfortunately roboticists are also interested in another important aspect, which is development cost.
In that aspect \glspl{FPGA} score pretty low due to the higher development complexity and required hardware engineering skills needed by developers.
That is also one of the reason why currently \glspl{FPGA} are not widely used in robotics.
Many \gls{FPGA} vendors have started to integrate \glspl{CPU} alongside \glspl{FPGA} in their \glspl{SOC}, so called \emph{Programmable \glspl{SOC}}\footnote{Xilinx calls the \gls{CPU} side \gls{PS}, and the \gls{FPGA} side \gls{PL}. This thesis will adopt this naming scheme.}.
This allows roboticists to use \glspl{CPU} for the general tasks of a robot (for which \glspl{CPU} have proven to be the perfect option), and selectively accelerate computationally heavy tasks in the accompanied \gls{FPGA}.
The tightly coupled nature of the programmable \glspl{SOC} together with the solutions and libraries provided by their respective vendors makes the integration of existing \gls{CPU} solutions easier.
The dawn of \gls{HLS}, in which a high level language (like C) is translated into usable \gls{HDL} code, is also a step towards wider \gls{FPGA} adoption.
The \gls{ROS} 2 communication, contrary to the \gls{ROS} 1 communication schema, relies on the \gls{DDS} and \gls{RTPS} specifications.
These are protocols that have not yet known (open-source) \gls{HDL} definitions and are thus impractical on \gls{FPGA} implementations.\\
The current way of connecting an \gls{HDL} defined module to a \gls{ROS} 2 system is to use a programmable \gls{SOC}, where a fully functional \gls{ROS} node is instantiated on the \gls{PS} side, and communicates via custom interfaces to the \gls{HDL} module residing in the \gls{PL} side.
Although this approach plays directly into the strengths of the programmable \glspl{SOC}, it has 2 major drawbacks.\\
The first one is that a programmable \gls{SOC} is required, which limits the choice of hardware components selected for the system.\\
The second is that the \gls{PS} side has to spend a significant amount of processing resources just to connect the \gls{PL} side to the \gls{ROS} network (both from the \gls{PS}-\gls{PL} interfaces and the \gls{SW} \gls{ROS} stack itself), which limits the use of the \gls{PS} for the actual required tasks in robotics.
This work provides a complete \gls{ROS} 2 stack in \gls{HDL}, which can be directly connected to a user-provided \gls{HDL} module and instantiated in an \gls{FPGA}.
This alleviates the need for a \gls{CPU} (and by extension the requirement for a programmable \gls{SOC}), and the \gls{CPU} can be used for more essential tasks.\\
By extension this work also provides the first open-source \gls{HDL} implementation of both the \gls{DDS} and \gls{RTPS} specifications, which will hopefully drive the wider adoption of \glspl{FPGA} using these field-proven protocols in the industry beyond the scope of robotics.
\cref{Chapter}{ch:background} gives insight on the \gls{ROS} framework, the \gls{DDS} protocol, and the \gls{RTPS} protocol.
\cref{Chapter}{ch:related-work} gives an overview of existing \gls{ROS} related \gls{FPGA} implementations.
\cref{Chapter}{ch:implementation} describes the actual \gls{HDL} implementation of all three parts (\gls{ROS}, \gls{DDS}, \gls{RTPS}) in detail.
\cref{Chapter}{ch:evaluation} describes the methods and results used to evaluate the implementation.
Finally \cref{Chapter}{ch:conclusion} holds the conclusion of this thesis and states the direction of future work.
\chapter{Background}
\label{ch:background}
\section{\acrshort{ROS}}
\label{sec:ros}
Despite it's name, \acrfull{ROS} is not a Operating System for robotics hardware, but an open-source software framework for robotics development, akin to an \gls{SDK} \cite{ros-ecosystem}.
The concept of \gls{ROS} was born around 2006 at Stanford University in an attempt to counter the development time that roboticists lose by re-implementing software infrastructure (hardware drivers and communication channels) on new projects \cite{ros-origin} \cite{ros-hist}.\\
In order to solve the above mentioned problem, \gls{ROS} encompasses not only a communication framework for processes, but also platform-independent build tools, code-reuse through distribution of existing software in the form of \gls{ROS} packages, coding conventions, and a thriving welcoming community.\\
\gls{ROS} is currently managed and maintained by Open Robotics, a subsidiary of \gls{OSRF}.
While \gls{ROS} began as the development environment for the Willow Garage PR2 robot, its wide adoption in many different robots, industries, and sectors introduced new use cases and showcased the limitations of the original base \gls{API} \cite{ros2-why}.\\
This led to the proposal of a major \gls{ROS} \gls{API} re-design at around 2014, which became to be known as \gls{ROS} 2 (whereas the previous \gls{ROS} \gls{API} revision as \gls{ROS} 1).
\subsection{Computation Graph Model}
\label{subsec:computation_graph_model}
%http://wiki.ros.org/Nodes
The \gls{ROS} framework operates in a computation graph model, in which independent computational entities are represented as \emph{nodes} \cite{ros-concept}.
This separation into nodes promotes fault isolation, faster development, modularity, and code re-usability.\\
These nodes communicate (connect) to each other via \emph{topics}, \emph{services}, and/or \emph{actions}.\\
A hierarchical naming structure called \emph{Graph Resource Names} allows resources in a \gls{ROS} Computation Graph, such as nodes, topics, services, and actions, to be defined within namespaces, providing encapsulation, which is critical for complicated systems compromised of many nodes.
\subsubsection{Topic}
\label{subsubsec:topic}
%http://wiki.ros.org/Topics
\begin{figure}[htp]
\centering
\includegraphics[width=\textwidth]{graphics/ros_topic.pdf}
\caption{\acrshort{ROS} Topic}
\label{fig:ros-topic}
\end{figure}
The primary communication between nodes occurs using a publish/subscribe schema via \emph{topics}.
In this, nodes publish \emph{messages} to specific topics, and other nodes can subscribe to these topics and receive the respective messages.\\
The format of the messages exchanged in a topic is predefined in \texttt{.msg} files, and is known by the respective publishers and subscribers of a topic.\\
This in effect allows many-to-many one-way communication between nodes.
\subsubsection{Service}
\label{subsubsec:service}
%http://wiki.ros.org/Services
\begin{figure}[htp]
\centering
\includegraphics[width=\textwidth]{graphics/ros_service.pdf}
\caption{\acrshort{ROS} Service}
\label{fig:ros-service}
\end{figure}
A \emph{service} allows request/reply interactions between nodes, in which a \emph{server} node offers a named service, and a \emph{client} node calls the service by sending a \emph{request}, and awaits a \emph{reply} from the server.\\
The message format of the requests and replies of a service are predefined in \texttt{.srv} files, and is known by the respective servers and clients of a service.
\subsubsection{Action}
\label{subsubsection:action}
%http://wiki.ros.org/actionlib
%http://design.ros2.org/articles/actions.html
\begin{figure}[htp]
\centering
\includegraphics[width=\textwidth]{graphics/ros_action.pdf}
\caption{\acrshort{ROS} (2) Action}
\label{fig:ros-action}
\end{figure}
An \emph{action}, similar to a service, is providing a request/reply interaction, but is meant for long running tasks, is non-blocking (for the client), and allows the client to cancel the task or ask for periodic feedback on the task execution status.\\
The message format of the request (\emph{goal}), reply (\emph{result}), and \emph{feedback} is predefined in \texttt{.action} files, and is known by the respective servers and clients of an action.
\subsection{Architectural Differences}
\label{subsec:architectural-differences}
The biggest difference between \gls{ROS} 1 and \gls{ROS} 2 is the underlying transport layer, responsible for the message transportation, and how it is used to implement the connection paradigms of the \gls{ROS} Computation Graph presented in \cref{Section}{subsec:computation_graph_model}.
\subsubsection{\acrshort{ROS} 1}
\label{subsubsec:ros1}
%http://wiki.ros.org/ROS/Technical%20Overview
%http://wiki.ros.org/Master
%http://wiki.ros.org/ROS/TCPROS
%http://wiki.ros.org/ROS/UDPROS
\begin{figure}[htp]
\centering
\includegraphics[width=\textwidth]{graphics/ros_1_architecture.pdf}
\caption{\acrshort{ROS} 1 Architecture}
\label{fig:ros1-architecture}
\end{figure}
\gls{ROS} 1 needs a central master node, called the \emph{\gls{ROS} Master}, that is used for registration and discovery purposes.
The role of the \gls{ROS} Master is to enable nodes to discover each other, by tracking all publishers and subscribers of topics and services.\\
Nodes register themselves to the \gls{ROS} Master via \gls{XML-RPC}, and get the \glspl{URI} of other nodes.
Using the \gls{URI}, nodes can then negotiate via \gls{XML-RPC} a direct data connection.
The message exchange between the nodes is happening directly (peer-to-peer) using either \emph{TCPROS} or \emph{UDPROS}.\\
The \gls{ROS} Master only acts as the mediator for the node discovery.\\
TCPROS is build on top of \gls{TCP}/\gls{IP}, whereas UDPROS is build on top of \gls{UDP}/\gls{IP}.
Both protocols are in-house developed exclusively for the purpose of \gls{ROS} message transportation.
%A MD5 hash of the message format files (\texttt{.msg} and \texttt{.srv}) is used to check if the communicating nodes are agreeing on the layout of the message data.
Topics and services are directly implemented into the \gls{ROS} core using the stated means.
Actions, on the other hand, are implemented as a separate \gls{ROS} package (\texttt{actionlib}), and are based on top of topics.
\subsubsection{\acrshort{ROS} 2}
\label{subsubsec:ros2}
\begin{figure}[htp]
\centering
\includegraphics[width=\textwidth]{graphics/ros2_API_architecture.pdf}
\caption{\acrshort{ROS} 2 (\acrshort{API}) Architecture}
\label{fig:ros2-architecture}
\end{figure}
Whereas the \gls{ROS} 2 user facing client \gls{API} has remained the same (at least conceptually), the underlying layers are different.
\gls{ROS} 2 swaps its transport layer for \gls{DDS}, a network standard based on the publish/subscribe schema.
\gls{DDS} is an open standard aimed for Real-Time Systems with many closed and open source implementations, and is extensively used in mission critical environments, such as battleships, large utility installations, financial systems, space systems, flight systems, and train switchboard systems \cite{dds-use} \cite{ros-dds}.
More on \gls{DDS} in \cref{Section}{sec:dds}.\\
The switch to \gls{DDS} decouples the dependency of \gls{ROS} on custom protocols (e.g. TCPROS), extends the capabilities of \gls{ROS} (e.g. Real-Time Support), shrinks the \gls{ROS} code-base and lowers the maintenance cost, since \gls{DDS} is maintained and developed by a 3rd party.
The fact that \gls{DDS} is also based on a publish/subscribe schema, allows a direct mapping of \gls{ROS} functionality with minimal effort.
Since \gls{DDS} also implements a fully decentralized node discovery mechanism, the dependency on \gls{ROS} Master is removed, making \gls{ROS} 2 fully decentralized.
As already mentioned, there exist numerous \gls{DDS} implementations, each with its respective advantages and disadvantages in terms of supported platforms, programming languages, performance characteristics, memory footprint, dependencies, and licensing.
In order to allow \gls{ROS} to support multiple different \gls{DDS} Implementations, the \emph{\gls{RMW}} Interface is introduced, which abstracts the \glspl{API} of \gls{DDS} implementations to the minimum functionality needed to support \gls{ROS} \cite{ros2-middleware}.\\
The \gls{ROS} release used in this work (\emph{Galactic Geochelone}) supports the \emph{eProsima Fast DDS}, \emph{Eclipse Cyclone DDS}, \emph{RTI Connext DDS}, and \emph{GurumNetworks GurumDDS} implementations \cite{ros2-vendor}.
The user facing client library layer was also modified, with the introduction of the \emph{\gls{RCL}} Interface, which defines an abstract \gls{ROS} client library on top of the \gls{RMW} \gls{API}.
The purpose of the \gls{RCL} \gls{API} is to provide a common implementation for more complex \gls{ROS} concepts and utilities that may be used by the user-facing language-specific client libraries (e.g. \texttt{rclcpp}), while remaining agnostic to the underlying \gls{RMW} \gls{API} being used \cite{ros2-api}.
In contrast, the \gls{ROS} 1 client libraries (\texttt{roscpp} and \texttt{rospy}) were build from scratch, and had therefore inherent differences between each other.
Similar to how \gls{ROS} 1 used message format files (\texttt{.msg}) to specify the message serialization, \gls{DDS} uses \gls{IDL} to specify the message serialization.
In order to allow backwards compatibility and allow the \gls{ROS} user-base to continue use the established message format files, generators that translate \texttt{.msg}, \texttt{.srv}, and \texttt{.action} files to \texttt{.idl} files were implemented.
Topics are directly implemented on \gls{DDS}, since it is directly mappable to the graph model used by \gls{DDS}.
Services are implemented on top of topics, and actions are implemented on top of services and topics.
In opposition to \gls{ROS} 1, the actions are implemented directly into the client library layer.
%MORE ROS1/ROS2 Differences https://roboticsbackend.com/ros1-vs-ros2-practical-overview/
% e.g. ROS2 can have multiple nodes in single process.
\section{\acrshort{DDS}}
\label{sec:dds}
As already mentioned in \cref{Section}{subsubsec:ros2}, \acrfull{DDS} is a field-proven open-standard middleware protocol specification defined by the \gls{OMG}.
The \gls{DDS} specification describes a \gls{DCPS} model for distributed application communication, and defines both the \glspl{API} and the communication semantics \cite{dds}.
The \gls{DDS} specification however avoids implementation details, allowing adopters of the specification freedom on the implementations of the defined functionality.
\gls{OMG} follows the \gls{MDA} approach and separates the \gls{DDS} specification into the \gls{PIM}, which defines the \gls{API} in a high abstraction level, and the \gls{PSM}, which maps the \gls{PIM} into the \gls{IDL}.
Since \gls{DDS} is Real-Time oriented, its interfaces are defined in a way that try to be predictable, and efficient with its use of resources.
This is done by allowing static resource pre-allocation, minimizing the need for data copying, and avoiding unbounded or hard-to-predict resources.
\gls{DDS} uses typed interfaces (interfaces that take into account the actual data type), implying the need for a generation tool to translate type descriptions into appropriate interfaces and implementations that fill the gap between the typed interfaces and the generic middleware.
\gls{DDS} uses \gls{QOS} policies to program service behavior, which gives rise to more flexibility, and a way to control determinism, overhead, and resource utilization.
The \gls{QOS} policies supported by \gls{DDS} are specified in \cref{Section}{subsec:qos-policies}.
This work is based on \gls{DDS} Specification version 1.4\cite{dds}.
\subsection{\acrshort{DCPS} Model}
\label{subsec:dcps-model}
\begin{figure}[htp]
\centering
\includegraphics[width=\textwidth]{graphics/DCPS_Model.pdf}
\caption{\acrshort{DCPS} Model}
\label{fig:dcps-model}
\end{figure}
%REF: DomainEntity is an intermediate object whose only purpose is to state that a DomainParticipant cannot contain other domain participants.
The \acrfull{DCPS} model builds on the concept of a \emph{global data space} that is accessible to all interested applications.
Publishers are contributing information to this data space, whereas subscribers access portions of this data space.
Each time a publisher posts new data into this global data space, the middleware propagates the information to all interested subscribers.
The global data space is segregated into \emph{domains}, that link all the applications able to communicate with each other.
Publishers and subscribers may only interact with publishers and subscribers of the same domain.
%REF: Therefore, another model, the Data-Centric Publish-Subscribe (DCPS) model, has become popular in many real-time applications. This model builds on the concept of a “global data space” that is accessible to all interested applications. Applications that want to contribute information to this data space declare their intent to become “Publishers.” Similarly, applications that want to access portions of this data space declare their intent to become “Subscribers.” Each time a Publisher posts new data into this “global data space,” the middleware propagates the information to all interested Subscribers. Underlying any data-centric publish subscribe system is a data model. This model defines the “global data space” and specifies how Publishers and Subscribers refer to portions of this space. The data-model can be as simple as a set of unrelated data-structures, each identified by a topic and a type. The topic provides an identifier that uniquely identifies some data items within the global data space1. The type provides structural information needed to tell the middleware how to manipulate the data and also allows the middleware to provide a level of type safety. However, the target applications often require a higher- level data model that allows expression of aggregation and coherence relationships among data elements.
The \gls{DCPS} model of \gls{DDS} is constructed of following \gls{DCPS} Entities:
\begin{description}
\item[DomainParticipant]
A \emph{DomainParticipant} represents the local membership of the application in a \emph{domain}.
A \emph{DomainParticipant} may contain one or more \emph{Publishers} and/or \emph{Subscribers}.
%REF: https://english.stackexchange.com/questions/13284/which-is-correct-one-or-more-is-or-one-or-more-are
\item[Publisher]
A \emph{Publisher} is responsible for data distribution.
It may publish data of different types.
A \emph{Publisher} may contain one or more \emph{DataWriters}.
\item[DataWriter]
A \emph{DataWriter} acts as a typed\footnote{Each \emph{DataWriter} is associated with a specific data type} accessor to a \emph{Publisher}.
An application uses the \emph{DataWriter} to publish data of a given type through a \emph{Publisher}.
\item[Subscriber]
A \emph{Subscriber} is responsible for receiving published data and making it available to the application.
It may receive and dispatch data of different types.
A \emph{Subscriber} may contain one or more \emph{DataReaders}.
\item[DataReader]
A \emph{DataReader} acts as a typed\footnote{Each \emph{DataReader} is associated with a specific data type} accessor to a \emph{Subscriber}.
An application uses the \emph{DataReader} to access received data of a given type from a \emph{Subscriber}.
\item[Topic]
A \emph{Topic} associates a name (unique in the domain) and type to data, that \emph{DataWriters} and \emph{DataReaders} can use to identify data in the global data space.
A \emph{Topic} can also be \emph{keyed}, which is achieved by defining some data fields as a key.
This key segregates the \emph{Topic} into different \emph{Instances}.
Different data values with the same key value represent successive values for the same \emph{Instance}, while different data values with different key values represent different \emph{Instances}.
\emph{Key-less} \emph{Topics} are restricted to a single \emph{Instance}\footnote{This thesis will use \emph{instance} and \emph{data-instance} interchangeably to refer to these topic instances.}.
\end{description}
A DataWriter can \emph{register}, \emph{unregister}, or \emph{dispose} data-instances.
In order for a DataWriter to publish data-samples for an instance, it has to register the instance first\footnote{The \gls{API} allows for the instance registration to happen implicitly on write operations.}.
The \emph{unregister} operation reverses the action of the \emph{register} operation, and informs the service that the DataWriter is not intending to modify this data-instance any more.
The \emph{dispose} operation requests the middleware to delete the data-instance (the actual deletion is postponed until there is no more use for that data in the whole system).
The \emph{dispose} operation is semantically different from the \emph{unregister} operation.
The \emph{dispose} operation indicates that the data-instance no longer exists, whereas the \emph{unregister} operation indicates that the writer is no longer taking responsibility for updating the value of the instance.
Deleting a DataWriter is equivalent to unregistering all the data-instances it was writing, but is not the same as disposing all the instances.
This thesis makes a distinction between \emph{active} and \emph{alive} DataWriters.
A DataWriter is \emph{alive} as defined by the LIVELINESS \gls{QOS} policy (see \cref{Section}{subsec:qos-policies}).
A DataWriter is \emph{active} in respect to an instance, if it is both \emph{alive} and has the respective instance registered.
This means that a DataWriter is not \emph{active} (in respect to an instance), either if it lost it's liveliness, or unregistered the instance.
%For each data-instance the service internally maintains a state variable that can take one of the following states:
Each data-instance can take one of the following states:
\begin{description}
\item[ALIVE]
This state indicates that data-samples have been received for the instance, there are \emph{active} DataWriters writing the instance, and the instance has not been explicitly disposed (or samples have been received after it was disposed).
\item[NOT_ALIVE_DISPOSED]
This state indicates that the instance was explicitly disposed by a DataWriter.
\item[NOT_ALIVE_NO_WRITERS]
This state indicates that the instance has been declared as not-alive by the DataReader because it detected that there are no \emph{active} DataWriters writing that instance.
\end{description}
As can be seen in \cref{Figure}{fig:dcps-model}, each \gls{DCPS} Entity has its own attached \gls{QOS} policy.
The \gls{QOS} of the \emph{Topic}, the \gls{QOS} of the \emph{DataWriter} associated with this \emph{Topic}, and the \gls{QOS} of the \emph{Publisher} associated to that \emph{DataWriter} control the behavior on the publishing side, whereas the corresponding \emph{Topic}, \emph{DataReader}, and \emph{Subscriber} \gls{QOS} control the behavior of the subscribing side.
All \gls{DCPS} Entities also accept \emph{Listeners}, \emph{Conditions} and \emph{WaitSets}.
\emph{Listeners} provide a mechanism for the middleware to asynchronously alert the application of the occurrence of relevant status changes (e.g. arrival of data, violation of \gls{QOS}).
\emph{Conditions}, in conjunction with \emph{WaitSets}, provide support for an alternative wait-based (synchronous) communication style with the middleware.
The \gls{DDS} Specification defines a set of built-in \emph{Topics} (DCPSParticipant, DCPSTopic, DCPSPublication, and DCPSSubscription) with associated built-in \emph{DataWriters} and \emph{DataReaders}, that the middleware uses in order to discover and possibly keep track of the presence of remote entities (see \cref{Section}{subsubsec:discovery-protocol}).
\subsection{\acrshort{QOS} Policies}
\label{subsec:qos-policies}
\gls{DDS} relies on the use of \acrfull{QOS}.
A \gls{QOS} is a set of characteristics that controls some aspects of the behavior of the \gls{DDS} service, and is comprised of individual \gls{QOS} policies.
Some \gls{QOS} policies have to be compatible between the publishing and subscribing side.
To maintain the desired de-coupling between the publishing and subscribing side, the \gls{DDS} service employs a subscriber-requested, publisher-offered pattern.
In this pattern, the subscriber side can specify a \emph{requested} value for a particular \gls{QOS} policy, and the publisher side specifies an \emph{offered} value for that \gls{QOS} policy.
The service will then determine whether the value requested by the subscriber side is compatible with what is offered by the publisher side, and if the two policies are compatible, then communication will be established.
Bellow is the List of supported \gls{QOS} policies by \gls{DDS}.
\gls{QOS} policies that have to be compatible between publisher and subscriber are marked in \textcolor{red}{red}.
\gls{QOS} policies that are optional according to the specification are marked in \textcolor{orange}{orange}.
% NOTE: ROS currently supports only a subset of DDS QoS
\begin{description}
\item[USER_DATA]
\textbf{Value:} Sequence of octets\\
\textbf{Default:} Empty Sequence\\
\textbf{Relevant \gls{DCPS} Entities:} DomainParticipant, DataReader, DataWriter\\
User provided data not known by the middleware.
\item[TOPIC_DATA]
\textbf{Value:} Sequence of octets\\
\textbf{Default:} Empty Sequence\\
\textbf{Relevant \gls{DCPS} Entities:} Topic\\
User provided data not known by the middleware.
\item[GROUP_DATA]
\textbf{Value:} Sequence of octets\\
\textbf{Default:} Empty Sequence\\
\textbf{Relevant \gls{DCPS} Entities:} Publisher, Subscriber\\
User provided data not known by the middleware.
\item[\textcolor{red}{DURABILITY}]
\textbf{Value:} \{VOLATILE, TRANSIENT_LOCAL, \textcolor{orange}{TRANSIENT}, \textcolor{orange}{PERSISTENT}\}\\
\textbf{Default:} VOLATILE\\
\textbf{Relevant \gls{DCPS} Entities:} Topic, DataReader, DataWriter\\
\textbf{Compatibility:} VOLATILE < TRANSIENT_LOCAL < TRANSIENT < PERSISTENT, with offered $\geq$ requested\\
This policy controls whether the service will actually make data available to late-joining subscribers.
\begin{description}
\item[VOLATILE]
The Service does not need to keep any samples of data-instances on behalf of any DataReader that is not known by the DataWriter at the time the instance is written.
\item[TRANSIENT_LOCAL]
The Service will attempt to keep some samples so that they can be delivered to any potential late-joining DataReader.
Which particular samples are kept depends on other \gls{QOS} (e.g. HISTORY and RESOURCE_LIMITS).
The service is only required to keep the data in the memory of the DataWriter that wrote the data and the data is not required to survive the DataWriter.
\item[\textcolor{orange}{TRANSIENT}]
Like TRANSIENT_LOCAL, but but the data is not tied to the lifecycle of the DataWriter and will, in general, survive it.
The service is only required to keep the data in memory and not in permanent storage.
\item[\textcolor{orange}{PERSISTENT}]
Like TRANSIENT, but data is kept on permanent storage, so that they can outlive a system session.
\end{description}
\item[\textcolor{orange}{DURABILITY_SERVICE}]
\textbf{Value:}
\begin{itemize}
\item \emph{service_cleanup_delay}: Duration
\item \emph{history_kind}: HISTORY \gls{QOS} policy
\item \emph{history_depth}: Integer
\item \emph{max_samples}: Integer
\item \emph{max_instances}: Integer
\item \emph{max_samples_per_instance}: Integer
\end{itemize}
\textbf{Default:}
\begin{itemize}
\item \emph{service_cleanup_delay}: Zero
\item \emph{history_kind}: KEEP_LAST
\item \emph{history_depth}: LENGTH_UNLIMITED
\item \emph{max_samples}: LENGTH_UNLIMITED
\item \emph{max_instances}: LENGTH_UNLIMITED
\item \emph{max_samples_per_instance}: LENGTH_UNLIMITED
\end{itemize}
\textbf{Relevant \gls{DCPS} Entities:} Topic, DataWriter\\
This policy specifies the configuration of the durability service, which is the service that implements the DURABILITY kind of TRANSIENT and PERSISTENT.
The durability service behaves "as if" for each topic that has TRANSIENT or PERSISTENT DURABILITY kind there was a corresponding "built-in" fictitious DataReader and DataWriter configured to have the same DURABILITY kind.
For each Topic, the "built-in" fictitious DataReader and DataWriter has its \gls{QOS} configured from the corresponding Topic \gls{QOS}.
As a consequence of this model, the durability service can be configured by means of setting the proper \gls{QOS} on the Topic\footnote{As a consequence, a DataWriter that has an incompatible \gls{QOS} with respect to the Topic \gls{QOS} will not send its data to the durability service, and a DataReader that has an incompatible \gls{QOS} with respect to the Topic \gls{QOS} will not get data from it.}.\\
\emph{service_cleanup_delay} controls when the service is able to remove all information regarding a data-instance\footnote{The data-instance has to be in a \emph{NOT_ALIVE_DISPOSED} state, and have no active DataWriters.}.\\
\emph{history_kind} and \emph{history_depth} controls the HISTORY \gls{QOS} policy of the fictitious DataReader that stores the data within the durability service, while \emph{max_samples}, \emph{max_instances}, and \emph{max_samples_per_instances} control its RESOURCE_LIMITS \gls{QOS} policy.
\item[\textcolor{red}{PRESENTATION}]
\textbf{Value:}
\begin{itemize}
\item \emph{access_scope}: \{INSTANCE, TOPIC, \textcolor{orange}{GROUP}\}
\item \emph{coherent_access}: Boolean
\item \emph{ordered_access}: Boolean
\end{itemize}
\textbf{Default:}
\begin{itemize}
\item \emph{access_scope}: INSTANCE
\item \emph{coherent_access}: FALSE
\item \emph{ordered_access}: FALSE
\end{itemize}
\textbf{Relevant \gls{DCPS} Entities:} Publisher, Subscriber\\
\textbf{Compatibility:}
\begin{itemize}
\item \emph{access_scope}: INSTANCE < TOPIC < GROUP, with offered $\geq$ requested
\item \emph{coherent_access}: requested = FALSE, or requested = offered = TRUE
\item \emph{ordered_access}: requested = FALSE, or requested = offered = TRUE
\end{itemize}
This policy specifies how the samples representing changes to data instances are presented to the subscribing application.
This policy affects the application’s ability to specify and receive coherent\footnote{The ability to group a set of changes as a unit on the publishing end such that they are received as a unit at the subscribing end.} changes (\emph{coherent_access}) and to see the relative order\footnote{The ability of the subscriber to see changes in the same order as they occurred on the publishing end.} of changes (\emph{ordered_access}).
\emph{access_scope} determines the largest scope spanning the entities for which the order and coherency of changes can be preserved:
\begin{description}
\item[INSTANCE]
Scope spans only a single instance (changes to one instance need not be coherent nor ordered with respect to changes to any other instance).
\item [TOPIC]
Scope spans to all instances within the same DataWriter (or DataReader), but not across instances in different DataWriters (or DataReaders).
\item [\textcolor{orange}{GROUP}]
Scope spans to all instances belonging to DataWriter (or DataReader) entities within the same Publisher (or Subscriber).
\end{description}
\item[\textcolor{red}{DEADLINE}]
\textbf{Value:} Duration (\emph{period})\\
\textbf{Default:} INFINITE\\
\textbf{Relevant \gls{DCPS} Entities:} Topic, DataReader, DataWriter\\
\textbf{Compatibility\footnote{It is inconsistent for a DataReader to have a DEADLINE period less than the minimum_separation of the TIME_BASED_FILTER.}:} offered $\leq$ requested\\
On the publishing side this policy indicates that a DataWriter commits to write a new value for each instance it manages at least once every deadline \emph{period}.\\
On the subscribing side this policy indicates that a DataReader expects a new sample updating the value of each instance at least once every deadline \emph{period}.\\
The fulfillment of this requirements are monitored by the service and the application is informed of any violations.
\item[\textcolor{red}{LATENCY_BUDGET}]
\textbf{Value:} Duration\\
\textbf{Default:} Zero\\
\textbf{Relevant \gls{DCPS} Entities:} Topic, DataReader, DataWriter\\
\textbf{Compatibility:} offered $\leq$ requested\\
This policy specifies the maximum acceptable delay from the time the data is written until the data is inserted in the receiver's application-cache and the receiving application is notified of the fact.
Thus this policy provides a means for the application to indicate to the middleware the "urgency" of the data-communication.
By having a non-zero duration the service can optimize its internal operation.
This policy is a hint to the service, not something that must be monitored or enforced.
\item[\textcolor{red}{OWNERSHIP}]
\textbf{Value:} \{SHARED, \textcolor{orange}{EXCLUSIVE}\}\\
\textbf{Default:} SHARED\\
\textbf{Relevant \gls{DCPS} Entities:} Topic, DataReader, DataWriter\\
\textbf{Compatibility:} offered = requested\\
This policy specifies whether it is allowed for multiple DataWriters to write the same instance of the data and if so, how these modifications should be arbitrated.
\begin{description}
\item[SHARED]
Indicates shared ownership for each instance.
Multiple writers are allowed to update the same instance and all the updates are made available to the readers.
\item[\textcolor{orange}{EXCLUSIVE}]
Indicates each instance can only be owned by one DataWriter, but the owner of an instance can change dynamically.
The owner is determined by selecting the DataWriter with the highest \emph{strength} (value of the OWNERSHIP_STRENGTH \gls{QOS} policy), that is both active and has not violated its DEADLINE contract with regards to the data-instance.
The behavior of the system is as if the ownership-determination was made independently by each DataReader\footnote{It is not a requirement that at a particular point in time all the DataReaders for that Topic have a consistent picture of who owns each instance. It is also not a requirement that the DataWriters are aware of whether they own a particular instance.}.
It is possible that multiple DataWriters with the same strength modify the same instance.
In this situation, the policy that selects which DataWriter is the owner is up to the implementation, but has to be consistent across all DataReaders.
\end{description}
\item[\textcolor{orange}{OWNERSHIP_STRENGTH}]
\textbf{Value:} Integer\\
\textbf{Default:} Zero\\
\textbf{Relevant \gls{DCPS} Entities:} DataWriter\\
This policy is used to determine the ownership of a data-instance.
It only applies if the OWNERSHIP \gls{QOS} policy is set to EXCLUSIVE.
\item[\textcolor{red}{LIVELINESS}]
\textbf{Value:}
\begin{itemize}
\item \emph{kind}: \{AUTOMATIC, MANUAL_BY_PARTICIPANT, MANUAL_BY_TOPIC\}
\item \emph{lease_duration}: Duration
\end{itemize}
\textbf{Default:}
\begin{itemize}
\item \emph{kind}: AUTOMATIC
\item \emph{lease_duration}: Infinite
\end{itemize}
\textbf{Relevant \gls{DCPS} Entities:} Topic, DataReader, DataWriter\\
\textbf{Compatibility:}
\begin{itemize}
\item \emph{kind}: AUTOMATIC < MANUAL_BY_PARTICIPANT < MANUAL_BY_TOPIC, with offered $\geq$ requested
\item \emph{lease_duration}: offered $\leq$ requested
\end{itemize}
This policy controls the mechanism and parameters used by the service to determine and ensure that DataWriters on the network are still \emph{alive}.
Liveliness must be asserted at least once every \emph{lease_duration}, otherwise the service will assume the
corresponding DataWriter is no longer \emph{alive}.
The DataReader requests that liveliness of the DataWriters is maintained by the requested means and loss of liveliness is detected with delay not to exceed the \emph{lease_duration}.
The DataWriter commits to signaling its liveliness using the stated means at intervals not to exceed the \emph{lease_duration}.
\begin{description}
\item[AUTOMATIC]
The service will automatically signal liveliness for the DataWriters at least as often as required by the \emph{lease_duration}.
\item[MANUAL_BY_PARTICIPANT]
The service will assume that as long as at least one DataWriter within the DomainParticipant has asserted its liveliness, the other DataWriters in that same DomainParticipant are also alive.
\item[MANUAL_BY_TOPIC]
The service will only assume liveliness of the DataWriter if the application has asserted liveliness of that DataWriter itself.
\end{description}
\item[TIME_BASED_FILTER]
\textbf{Value:} Duration (\emph{minimum_seperation})\\
\textbf{Default:} Zero\\
\textbf{Relevant \gls{DCPS} Entities:} DataReader\\
This policy defines a filter that allows a DataReader to specify that it is interested only in (potentially) a subset of the values of each instance published under a topic.
The filter states that the DataReader does not want to receive more than one value each \emph{minimum_separation} duration for each instance, regardless of how fast the changes occur.
\item[PARTITION]
\textbf{Value:} Sequence of Strings\\
\textbf{Default:} Empty Sequence\\
\textbf{Relevant \gls{DCPS} Entities:} Publisher, Subscriber\\
This policy introduces a logical partition among the topics visible by the Publisher and Subscriber in a domain.
A DataWriter within a Publisher only communicates with a DataReader in a Subscriber if (in addition to matching the Topic and having compatible QoS) the Publisher and Subscriber have a common \emph{partition name} string.
Each string in the list that defines this policy, defines a \emph{partition name}\footnote{\emph{Partition names} can be regular expressions and include wildcards as defined by the POSIX fnmatch \gls{API} (1003.2-1992 section B.6).}.
Failure to match partitions is not considered an incompatible \gls{QOS}.
\item[\textcolor{red}{RELIABILITY}]
\textbf{Value:}
\begin{itemize}
\item \emph{kind}: \{RELIABLE, BEST_EFFORT\}
\item \emph{max_blocking_time}: Duration
\end{itemize}
\textbf{Default:}
\begin{itemize}
\item \emph{kind}: RELIABLE (DataWriter), BEST_EFFORT (DataReader, Topic)
\item \emph{lease_duration}: 100 ms
\end{itemize}
\textbf{Relevant \gls{DCPS} Entities:} Topic, DataReader, DataWriter\\
\textbf{Compatibility:}
\begin{itemize}
\item \emph{kind}: BEST_EFFORT < RELIABLE, with offered $\geq$ requested
\item \emph{lease_duration}: Ignored
\end{itemize}
This policy Indicates the level of reliability offered/requested by the Service.
\begin{description}
\item[BEST_EFFORT]
The service will not re-transmit missing data-samples.
However for data-samples originating from any one DataWriter the service will ensure they are stored in the DataReader history in the same order they originated in the DataWriter.
\item[RELIABLE]
Data-samples originating from a single DataWriter cannot be made available to the DataReader if there are previous data-samples that have not been received yet due to a communication error.
The service will re-transmit those missing data-samples.
\end{description}
The value of \emph{max_blocking_time} is relevant only to DataWriters and indicates the maximum time the \emph{write} operation of the DataWriter is allowed to block if not enough space\footnote{If kind is RELIABLE and according to the RESOURCE_LIMITS \gls{QOS}.} is available to store the written value.
\item[TRANSPORT_PRIORITY]
\textbf{Value:} Integer\\
\textbf{Default:} Zero\\
\textbf{Relevant \gls{DCPS} Entities:} Topic, DataWriter\\
This policy is a hint to the service as to how to set the priority of the underlying transport used to send the data.
Any value within the range of a 32-Bit signed integer may be chosen, with higher values indicating a higher priority.
\item[LIFESPAN]
\textbf{Value:} Duration\\
\textbf{Default:} Infinite\\
\textbf{Relevant \gls{DCPS} Entities:} Topic, DataWriter\\
This policy specifies the maximum duration of validity of the data written by the DataWriter.
On expiration, the data will be removed from the DataWriter and DataReader caches.
The expiration time of each data-sample is computed by adding the duration specified by this policy to the source timestamp\footnote{This \gls{QOS} policy relies on the sender and receiving applications having their clocks sufficiently synchronized. If this is not the case, the DataReader is allowed to use the reception timestamp instead of the source timestamp in its computation of the expiration time.}.
\item[\textcolor{red}{DESTINATION_ORDER}]
\textbf{Value:} \{BY_RECEPTION_TIMESTAMP, BY_SOURCE_TIMESTAMP\}\\
\textbf{Default:} BY_RECEPTION_TIMESTAMP\\
\textbf{Relevant \gls{DCPS} Entities:} Topic, DataReader, DataWriter\\
\textbf{Compatibility:} BY_RECEPTION_TIMESTAMP < BY_SOURCE_TIMESTAMP, with offered $\geq$ requested\\
This policy controls the criteria used to determine the logical order among changes made by DataWriters to the same data-instance.
\begin{description}
\item[BY_RECEPTION_TIMESTAMP]
Indicates that data is ordered based on the reception time at each DataReader.
Consequently, it is possible for each DataReader to end up with a different final value for the data.
\item[BY_SOURCE_TIMESTMAP]
Indicates that data is ordered based on the source timestamp placed from the DataWriter.
This guarantees a consistent final value for the data in all DataReaders.
\end{description}
\item[HISTORY]
\textbf{Value:}
\begin{itemize}
\item \emph{kind}: \{KEEP_LAST, KEEP_ALL\}
\item \textcolor{orange}{\emph{depth}}: Integer
\end{itemize}
\textbf{Default:}
\begin{itemize}
\item \emph{kind}: KEEP_LAST
\item \textcolor{orange}{\emph{depth}}: 1\footnote{If a value other than 1 is specified, it should be consistent with the settings of the RESOURCE_LIMITS \gls{QOS} policy.}
\end{itemize}
\textbf{Relevant \gls{DCPS} Entities:} Topic, DataReader, DataWriter\\
This policy controls the behavior of the service when the value of an instance changes before it is finally communicated to some of its existing DataReader entities.
On the publishing side this policy controls the samples that should be maintained by the DataWriter on behalf of existing DataReaders\footnote{The behavior with regards to DataReaders discovered after a sample is written is controlled by the DURABILITY \gls{QOS} policy.}.
On the subscribing side this policy controls the samples that should be maintained until the application \emph{takes}\footnote{\gls{DDS} differentiates between \emph{take} and \emph{read} operations. The \emph{read} operation retrieves the sample, without removing it from the list (so it can be retrieved again), whereas \emph{take} removes it.} them from the service.
\begin{description}
\item[KEEP_LAST]
On the publishing side, the service will only attempt to keep the most recent \emph{depth} samples of each data-instance managed by the DataWriter.
On the subscribing side, the DataReader will only attempt to keep the most recent \emph{depth} samples received for each data-instance until the application \emph{takes} them from the DataReader.
\item[KEEP_ALL]
On the publishing side, the service will attempt to keep all samples of each data-instance managed by the DataWriter until they can be delivered to all relevant DataReaders.
On the subscribing side, the service will attempt to keep all samples of each data-instance managed by the DataReader until the application \emph{takes} them from the service.
The resources that the service can use to keep this history are limited by the settings of the RESOURCE_LIMITS \gls{QOS} policy.
If the limit is reached, then the behavior of the service will depend on the RELIABILITY \gls{QOS} policy.
If the RELIABILITY \gls{QOS} policy is BEST_EFFORT, then the old values will be discarded.
If the RELIABILITY \gls{QOS} policy is RELIABLE, a DataReader will not accept the sample delivery (drop the sample) until resources are freed up via a \emph{take} operation by the application, whereas a DataWriter will block until it can deliver the necessary old values to all subscribers before replacing them.
\end{description}
\item[RESOURCE_LIMITS]
\textbf{Value:}
\begin{itemize}
\item \emph{max_samples}: Integer
\item \emph{max_instances}: Integer
\item \emph{max_samples_per_instance}: Integer
\end{itemize}
\textbf{Default:}
\begin{itemize}
\item \emph{max_samples}: LENGTH_UNLIMITED
\item \emph{max_instances}: LENGTH_UNLIMITED
\item \emph{max_samples_per_instance}: LENGTH_UNLIMITED\footnote{It is inconsistent for this value to be greater than \emph{max_samples}.}\footnote{It is inconsistent for this value to be less than the \emph{depth} value from the HISTORY \gls{QOS} policy.}
\end{itemize}
\textbf{Relevant \gls{DCPS} Entities:} Topic, DataReader, DataWriter\\
This policy specifies the resources that the Service can consume in order to meet the requested \gls{QOS} policies.
\emph{max_samples} specifies the maximum number of samples the DataWriter (or DataReader) can manage across all the data-instances associated with it, and represents the maximum samples the middleware can store for any one DataWriter (or DataReader).
\emph{max_instances} specifies the maximum number of data-instances a DataWriter (or DataReader) can manage.
\emph{max_samples_per_instance} specifies the maximum number of samples any one data-instance of a DataWriter (or DataReader) can manage.
\item[ENTITY_FACTORY]
\textbf{Value:} Boolean (\emph{autoenable_created_entities})\\
\textbf{Default:} True\\
\textbf{Relevant \gls{DCPS} Entities:} DomainParticipant, Publisher, Subscriber\\
This policy controls the side-effects of the create_* and delete_* operations of the entity.
\emph{autoenable_created_entities} specifies whether the entity acting as a factory automatically enables the entities it creates.
\item[WRITER_DATA_LIFECYCLE]
\textbf{Value:} Boolean (\emph{autodispose_unregistered_instances})\\
\textbf{Default:} True\\
\textbf{Relevant \gls{DCPS} Entities:} DataWriter\\
This policy specifies the behavior of the DataWriter with regards to the lifecycle of the data-instances it manages.
\emph{autodispose_unregistered_instances} controls whether a DataWriter will automatically dispose instances each time they are unregistered.
\item[READER_DATA_LIFECYCLE]
\textbf{Value:}
\begin{itemize}
\item \emph{autopurge_nowriter_samples_delay}: Duration
\item \emph{autopurge_disposed_samples_delay}: Duration
\end{itemize}
\textbf{Default:}
\begin{itemize}
\item \emph{autopurge_nowriter_samples_delay}: Infinite
\item \emph{autopurge_disposed_samples_delay}: Infinite
\end{itemize}
\textbf{Relevant \gls{DCPS} Entities:} DataReader\\
This policy specifies the behavior of the DataReader with regards to the lifecycle of the data-instances it manages.
\emph{autopurge_nowriter_samples_delay} indicates the duration the DataReader must retain information regarding instances that have the instance state \emph{NOT_ALIVE_NO_WRITERS}.
\emph{autopurge_disposed_samples_delay} indicates the duration the DataReader must retain information regarding instances that have the instance state \emph{NOT_ALIVE_DISPOSED}.
\end{description}
\section{\acrshort{RTPS}}
\label{sec:rtps}
The \gls{DDS} specification does not address the protocol used by the implementation to exchange messages over transports, so different implementations of \gls{DDS} will not interoperate with each other unless vendor-specific bridges are provided.\\
The \acrfull{RTPS} protocol specification defined by the \gls{OMG} consortium is an interoperability wire protocol for the \gls{DDS} specification\cite{rtps}, providing a common protocol that vendors can use to achieve interoperability.
Like the \gls{DDS} specification, the \gls{RTPS} specification is also using the \gls{MDA} approach and defines the higher abstraction level \gls{PIM}, and a \gls{PSM} which maps the \gls{PIM} to \gls{UDP}/\gls{IP}.
Although the \gls{RTPS} protocol found its roots in industrial automation, and was in fact approved by the \gls{IEC} as part of the Real-Time Industrial Ethernet Suite IEC-PAS-62030\cite{rtps}, the industrial automation community defined requirements for a standard publish-subscribe wire-protocol that closely matched those of \gls{DDS}, and was thus selected as the wire-protocol for \gls{DDS}.
The \gls{RTPS} protocol has proven its performance and applicability to \gls{DDS} in the 14 years since its adoption\footnote{Version 2.0 of the \gls{RTPS} protocol released in April 2008 was the first version after the protocol was adopted by \gls{OMG} as an interoperability wire-protocol for \gls{DDS}.}, and \gls{OMG} has performed interoperability demonstrations among many different implementations, including the \gls{DDS}/\gls{RTPS} implementations from Real-Time Innovations (Connext DDS and Connext DDS Micro), ADLink (OpenSplice DDS, Vortex Cafe, and CycloneDDS), TwinOaks Computing (CoreDX DDS), Kongsberg (InterComm DDS), Object Computing Incorporated (OpenDDS), and eProsima (FastRTPS)\cite{rtps}.
This work is based on \gls{DDSI-RTPS} Specification version 2.3\cite{rtps}.
%REF: The desired wire protocol must be capable of exploiting the multicast, best-effort, and connectionless nature of many of the DDS QoS settings.
\subsection{\acrshort{RTPS} Structure}
\label{subsec:rtps-structure}
\begin{figure}[htp]
\centering
\includegraphics[width=\textwidth]{graphics/RTPS-DDS_relation.pdf}
\caption{\acrshort{RTPS}-\acrshort{DDS} Entity Relation}
\label{fig:rtps-dds-relation}
\end{figure}
In order to describe the protocol in a complete and unambiguous manner, the \gls{PIM} describes the protocol in terms of a \emph{\gls{VM}}.
The \gls{RTPS} \gls{VM} consists of following Entities: \hyperref[subsubsec:rtps-entity]{\gls{RTPS} Entity}, \hyperref[subsubsec:rtps-participant]{\gls{RTPS} Participant}, \hyperref[subsubsec:rtps-group]{\gls{RTPS} Group}, \hyperref[subsubsec:rtps-endpoint]{\gls{RTPS} Endpoint}, \hyperref[subsubsec:rtps-writer]{\gls{RTPS} Writer}, \hyperref[subsubsec:rtps-reader]{\gls{RTPS} Reader}, \hyperref[subsubsec:rtps-historycache]{\gls{RTPS} HistoryCache}, and \hyperref[subsubsec:rtps-cachechange]{\gls{RTPS} CacheChange}, which are described in the following Sections.
%REF: Given its publish-subscribe roots, RTPS maps naturally to many DDS concepts. This specification uses many of the same core entities used in the DDS specification. As illustrated in Figure 7.2, all RTPS entities are associated with an RTPS domain, which represents a separate communication plane that contains a set of Participants. A Participant contains Groups which contain local Endpoints. There are two kinds of endpoints: Readers and Writers. Readers and Writers are the actors that communicate information by sending RTPS messages. Writers inform of the presence and send locally available data on the Domain to the Readers which can request and acknowledge the data.
\subsubsection{\acrshort{RTPS} Entity}
\label{subsubsec:rtps-entity}
\textbf{Attributes:}
\begin{itemize}
\item \emph{\gls{GUID}}
\end{itemize}
The \emph{\gls{RTPS} Entity} is the base class for all \gls{RTPS} Entities, and represents the class of objects that are visible to other \gls{RTPS} Entities on the network.
For this purpose all \emph{\gls{RTPS} Entity} objects have a \gls{GUID}, which identifies the \emph{\gls{RTPS} Entity} globally and uniquely within a domain.
An \emph{\gls{RTPS} Entity} maps directly to a \emph{\gls{DDS} Entity}.
The \gls{GUID} is built by combining a \emph{\gls{GUID} Prefix} and an \emph{Entity \gls{ID}}.
The \gls{GUID} Prefix uniquely identifies the \emph{\gls{RTPS} Participant} within the domain, while the Entity \gls{ID} uniquely identifies the \emph{\gls{RTPS} Entity} within an \emph{\gls{RTPS} Participant}.
\subsubsection{\acrshort{RTPS} Participant}
\label{subsubsec:rtps-participant}
\textbf{Attributes:}
\begin{itemize}
\item Default Unicast Locator List
\item Default Multicast Locator List
\item Protocol Version
\item Vendor \gls{ID}
\end{itemize}
The \emph{\gls{RTPS} Participant} is a container for \emph{\gls{RTPS} Endpoint} Entities that share common properties and are located in a single address space.
An \emph{\gls{RTPS} Participant} maps directly to a \emph{\gls{DDS} DomainParticipant}.
The \emph{Default Unicast Locator List} and \emph{Default Multicast Locator List} attributes define lists of default unicast and multicast locators\footnote{Type used to represent the addressing information needed to send a message to an \emph{\gls{RTPS} Endpoint} using one of the supported transports.} that can be used to communicate with the \emph{\gls{RTPS} Endpoints} contained in the \emph{\gls{RTPS} Participant}, if the underlying \emph{\gls{RTPS} Endpoints} do not specify their own set of locators.
The \emph{Protocol Version} attribute identifies the version of the \gls{RTPS} protocol that the \emph{\gls{RTPS} Participant} uses to communicate, and the \emph{Vendor \gls{ID}} attribute identifies the vendor of the \gls{RTPS} middleware that contains the \emph{\gls{RTPS} Participant}.
\subsubsection{\acrshort{RTPS} Group}
\label{subsubsec:rtps-group}
The \emph{\gls{RTPS} Group} is a container for \emph{\gls{RTPS} Endpoint} Entities, and provides a way for \emph{\gls{RTPS} Endpoints} to share common properties.
There are two kinds of \emph{\gls{RTPS} Group} Entities:
\begin{description}[style=standard]
\item[\gls{RTPS} Publisher:] Contains \emph{\gls{RTPS} Writer} Endpoints. An \emph{\gls{RTPS} Publisher} maps directly to a \emph{\gls{DDS} Publisher}.
\item[\gls{RTPS} Subscriber:] Contains \emph{\gls{RTPS} Reader} Endpoints. An \emph{\gls{RTPS} Subscriber} maps directly to a \emph{\gls{DDS} Subscriber}
\end{description}
\subsubsection{\acrshort{RTPS} Endpoint}
\label{subsubsec:rtps-endpoint}
\textbf{Attributes:}
\begin{itemize}
\item Unicast Locator List
\item Multicast Locator List
\item Reliability Level
\item Topic Kind \{NO_KEY, WITH_KEY\}
\end{itemize}
The \emph{\gls{RTPS} Endpoint} is a specialization of \emph{\gls{RTPS} Entity} representing the objects that can be communication endpoints (objects that can be the sources or destinations of \gls{RTPS} Messages).
The \emph{Unicast Locator List} and \emph{Multicast Locator List} attributes define lists of unicast and multicast locators that can be used to communicate with the \emph{\gls{RTPS} Endpoint}.
The \emph{Reliability Level} attribute defines levels of reliability supported by the \emakefirstuc{\gls{RTPS} Endpoint}, and maps directly to the RELIABILITY \gls{QOS} policy of the \gls{DDS} specification.
The \emph{Topic Kind} attribute defines whether the \emph{\gls{RTPS} Endpoint} supports keyed or key-less \gls{DDS} Topics as defined in \cref{Section}{subsec:dcps-model}.
\emph{\gls{RTPS} Endpoints} with \emph{Topic Kind} WITH_KEY support instance lifecycle management operations.
\cref{Section}{subsubsec:built-in-rtps-endpoint} describes some pre-defined \emph{built-in \gls{RTPS} Endpoints} that are defined by the \gls{RTPS} Specification.
\subsubsection{\acrshort{RTPS} Writer}
\label{subsubsec:rtps-writer}
\textbf{Attributes:}
\begin{itemize}
\item Push Mode
\item Heartbeat Period
\item Nack Response Delay
\item Nack Suppression Duration
\item Last Change Sequence Number
\item Writer Cache
\item Data Max Size Serialized
\end{itemize}
The \emph{\gls{RTPS} Writer} specializes \emph{\gls{RTPS} Endpoint} and represents the actor that sends \emph{\gls{RTPS} CacheChange} Messages to the matched \emph{\gls{RTPS} Reader} Endpoints.
An \emph{\gls{RTPS} Writer} belongs to an \emph{\gls{RTPS} Group} of type \emph{\gls{RTPS} Publisher}.
An \emph{\gls{RTPS} Writer} directly maps to a \emph{\gls{DDS} DataWriter}.
The \emph{Push Mode} attribute configures if the \emph{\gls{RTPS} Writer} sends (pushes) new \emph{\gls{RTPS} CacheChanges} immediately, or only announces them via \emph{HEARTBEAT \gls{RTPS} Submessages}\footnote{see \cref{Section}{subsubsec:rtps-submessage}.\label{footref:rtps-submes}} and sends them instead as response to the \emph{ACKNACK \gls{RTPS} Submessage}\footref{footref:rtps-submes} request of an \emph{\gls{RTPS} Reader}.
The \emph{Heartbeat Period}, \emph{Nack Response Delay}, and \emph{Nack Suppression Duration} attributes are protocol tuning parameters, that allow to configure the sending period between \emph{HEARTBEAT \gls{RTPS} Submessages}\footref{footref:rtps-submes}, the response delay to an \emph{ACKNACK \gls{RTPS} Submessage}\footref{footref:rtps-submes} (negative acknowledgment) from an \emph{\gls{RTPS} Reader}, and the duration where requests from \emph{ACKNACK \gls{RTPS} Submessages}\footref{footref:rtps-submes} (negative acknowledgments) are ignored after the corresponding requested \emph{\gls{RTPS} CacheChange} is already sent, respectively.
The \emph{Last Change Sequence Number} attribute is an internal counter used to assign increasing sequence numbers to each \emph{\gls{RTPS} CacheChange} made by the \emph{\gls{RTPS} Writer}.
The \emph{Data Max Size Serialized} attribute is optional and indicates the maximum size of the payload that may be sent by the \emph{\gls{RTPS} Writer}.
The \emph{Writer Cache} attribute is an \emph{\gls{RTPS} HistoryCache} containing a collection of \emph{\gls{RTPS} CacheChanges} made by the \emph{\gls{RTPS} Writer}.
The role of the \emph{\gls{RTPS} Writer} is to transfer all \emph{\gls{RTPS} CacheChanges} in its local \emph{\gls{RTPS} HistoryCache} to the \emph{\gls{RTPS} HistoryCaches} of the matching remote \emph{\gls{RTPS} Readers}.
%REF: Specialization of RTPS Endpoint representing the objects that can be the sources of messages communicating CacheChanges.
\subsubsection{\acrshort{RTPS} Reader}
\label{subsubsec:rtps-reader}
\begin{itemize}
\item Heartbeat Response Delay
\item Heartbeat Suppression Duration
\item Reader Cache
\item Expects Inline QoS
\end{itemize}
The \emph{\gls{RTPS} Reader} specializes \emph{\gls{RTPS} Endpoint} and represents the actor that receives \emph{\gls{RTPS} CacheChange} Messages from the matched \emph{\gls{RTPS} Writer} Endpoints.
An \emph{\gls{RTPS} Reader} belongs to an \emph{\gls{RTPS} Group} of type \emph{\gls{RTPS} Subscriber}.
An \emph{\gls{RTPS} Reader} directly maps to a \emph{\gls{DDS} DataReader}.
The \emph{Heartbeat Response Delay}, and \emph{Heartbeat Suppression Duration} attributes are protocol tuning parameters, that allow to configure the response delay to a \emph{HEARTBEAT \gls{RTPS} Submessage}\footref{footref:rtps-submes} from an \emph{\gls{RTPS} Writer}, and the duration after the arrival of a \emph{HEARTBEAT \gls{RTPS} Submessage}\footref{footref:rtps-submes} where further received \emph{HEARTBEAT \gls{RTPS} Submessages}\footref{footref:rtps-submes} can be ignored, respectively.
The \emph{Reader Cache} attribute is an \emph{\gls{RTPS} HistoryCache} containing a collection of \emph{\gls{RTPS} CacheChanges} made by the matched \emph{\gls{RTPS} Writers}.
The \emph{Expects Inline QoS} attribute specifies whether the \emph{\gls{RTPS} Reader} expects in-line \gls{QOS} to be sent along with the data payload by the \emph{\gls{RTPS} Writers}\footnote{See DATA Submessage in \cref{Section}{par:entity-submessages}.}.
%REF: Specialization of RTPS Endpoint representing the objects that can be used to receive messages communicating CacheChanges.
\subsubsection{\acrshort{RTPS} HistoryCache}
\label{subsubsec:rtps-historycache}
\textbf{Attributes:}
\begin{itemize}
\item changes
\end{itemize}
The \emph{\gls{RTPS} HistoryCache} is used to temporarily store and manage \emph{\gls{RTPS} CacheChanges} (Contained in the \emph{changes} attribute).\\
On the writer side, the \emph{\gls{RTPS} HistoryCache} contains the \emph{partial\footnote{Only a subset of the whole history is needed to meet the behavioral needs of the \gls{RTPS} protocol and the \gls{QOS} needs of the related \gls{DDS} entities.\label{footref:partial}}} history of changes to data-objects made by the
corresponding \emph{\gls{RTPS} Writer}.\\
On the reader side, the \emph{\gls{RTPS} HistoryCache} contains the \emph{partial\footref{footref:partial}} superposition of changes to data-objects made by all the matched \emph{\gls{RTPS} Writer} Endpoints.
The \emph{\gls{RTPS} HistoryCache} is part of the interface between \gls{DDS} and \gls{RTPS}, therefore both the \gls{RTPS} Entities and their related \gls{DDS} Entities are able to invoke the operations on their associated \emph{\gls{RTPS} HistoryCache}.
\subsubsection{\acrshort{RTPS} CacheChange}
\label{subsubsec:rtps-cachechange}
\textbf{Attributes:}
\begin{itemize}
\item \emph{ChangeKind} \{ALIVE, ALIVE_FILTERED, NOT_ALIVE_DISPOSED,NOT_ALIVE_UNREGISTERED\}
\item \emph{WriterGUID}
\item \emph{InstanceHandle}
\item \emph{SequenceNumber}
\item \emph{InlineQoS}
\item \emph{DataValue}
\end{itemize}
The \emph{\gls{RTPS} CacheChange}\footnote{The terms \emph{CacheChange} and \emph{Sample} (Mainly used by the \gls{DDS} specification) will be used interchangeably in this thesis.} is used to represent an individual change made to a data-object, including the creation, modification, and deletion of data-objects.
The \emph{ChangeKind} attribute is used to distinguish the kind of change that was made to a data-object or its instance state.
This attribute is closely related to the instance states (and their lifecycle management) defined in the \gls{DDS} specification.
The \emph{WriterGUID} attribute contains the origin \gls{GUID} and identifies the \emph{\gls{RTPS} Writer} that made the change.
The \emph{InstanceHandle} identifies the data-instance to which the change applies\footnote{It is thus closely related to the Key fields of a Topic in the \gls{DDS} specification.}.
The \emph{SequenceNumber} attribute is assigned by the \emph{\gls{RTPS} Writer} to uniquely identify the change.
The \emph{InlineQoS} attribute contains a list of \gls{QOS} that may affect the interpretation of the \emph{DataValue} (may be empty).
The \emph{DataValue} attribute contains the data value associated with the change, which depending on the \emph{ChangeKind} may be empty (no associated data)\footnote{Only \emph{\gls{RTPS} CacheChanges} with \emph{ChangeKind} ALIVE have associated data.}.
\subsubsection{Built-in \acrshort{RTPS} Endpoint}
\label{subsubsec:built-in-rtps-endpoint}
The \gls{RTPS} Specification defines built-in \emph{\gls{RTPS} Endpoints}, with which \emph{\gls{RTPS} Participants} can exchange information. The \gls{RTPS} Specification names the traffic between these built-in \emph{\gls{RTPS} Endpoints} as \emph{"meta-traffic"}, whereas traffic between user-defined \emph{\gls{RTPS} Endpoints} as \emph{"user-traffic"}.
The \gls{RTPS} Specification maps each built-in \emph{\gls{DDS} DataWriter} and \emph{\gls{DDS} DataReader} of the built-in \emph{\gls{DDS} Topics} defined by the \gls{DDS} Specification to an associated built-in \emph{\gls{RTPS} Writer} and \emph{\gls{RTPS} Reader}:
\begin{tabular}{|l|l|l|}
\hline
\textbf{TOPIC} & \textbf{\acrshort{RTPS} ENDPOINTS} & \textbf{DATA TYPE} \\
\hline
\multirow{2}{*}{DCPSParticipant} & SPDPbuiltinParticipantWriter & \multirow{2}{*}{SPDPdiscoveredParticipantData}\\
\cline{2-2}
& SPDPbuiltinParticipantReader & \\
\hline
\multirow{2}{*}{DCPSPublication} & SEDPbuiltinPublicationsWriter & \multirow{2}{*}{DiscoveredWriterData}\\
\cline{2-2}
& SEDPbuiltinPublicationsReader & \\
\hline
\multirow{2}{*}{DCPSSubscription} & SEDPbuiltinSubscriptionsWriter & \multirow{2}{*}{DiscoveredReaderData}\\
\cline{2-2}
& SEDPbuiltinSubscriptionsReader & \\
\hline
\multirow{2}{*}{DCPSTopic} & SEDPbuiltinTopicWriter & \multirow{2}{*}{DiscoveredTopicData}\\
\cline{2-2}
& SEDPbuiltinTopicReader & \\
\hline
\end{tabular}
The data types of these built-in \emph{\gls{RTPS} Endpoints} are described in \cref{Section}{subsubsec:discovery-protocol}.
In addition the \gls{RTPS} Specification also defines a general purpose built-in \emph{\gls{DDS} Topic} with associated \emph{\gls{RTPS} Endpoints}:
\begin{tabular}{|l|l|l|}
\hline
\textbf{TOPIC} & \textbf{\acrshort{RTPS} ENDPOINTS} & \textbf{DATA TYPE} \\
\hline
\multirow{2}{*}{DCPSParticipantMessage} & BuiltinParticipantMessageWriter & \multirow{2}{*}{ParticipantMessageData}\\
\cline{2-2}
& BuiltinParticipantMessageReader & \\
\hline
\end{tabular}
Currently the \emph{DCPSParticipantMessage} Topic is used to implement the \emph{\gls{DDS} LIVELINESS \gls{QOS}} (see \cref{Section}{par:liveliness}).
\paragraph{ParticipantMessageData}\mbox{}\\
\label{par:participantmessagedata}
Fields:
\begin{itemize}
\item \emph{ParticipantGuidPrefix} \textbf{[Topic Key]}
\item \emph{Kind} \{UNKNOWN, AUTOMATIC_LIVELINESS_UPDATE, MANUAL_LIVELINESS_UPDATE\} \textbf{[Topic Key]}
\item \emph{Data}
\end{itemize}
The \emph{ParticipantGuidPrefix} field contains the \gls{GUID} Prefix of the Participant that is writing the data.
Since the \gls{RTPS} Specification only specifies how to use the \emph{ParticipantMessageData} to implement the \emph{LIVELINESS \gls{QOS}}, the \emph{Kind} field currently only distinguishes between the types of liveliness updates.\\
The \gls{RTPS} Specification also reserves a range of the \emph{Kind} field, that vendors can use for vendor specific messaging.
The \emph{Data} field is an unspecified array of Bytes.
The \gls{RTPS} Specification states that implementations can decide on the upper length of the \emph{Data} field, but must be able to support at least 128 Bytes.
For the purposes of liveliness assertion, the \emph{Data} field is empty.
\subsection{\acrshort{RTPS} Message}
\label{subsec:rtps-message}
The overall structure of an \emph{\gls{RTPS} Message} consists of a fixed-size leading \hyperref[subsubsec:rtps-header]{\gls{RTPS} Header} followed by a variable number of \hyperref[subsubsec:rtps-submessage]{\gls{RTPS} Submessage} parts, which are described in the following sections.
The number of \emph{\gls{RTPS} Submessages} that can be sent in a single \emph{\gls{RTPS} Message} is only limited by the maximum message size the underlying transport can support.
Due to their modular design, \emph{\gls{RTPS} Messages} can be easily extended to support both standard protocol feature additions as well as vendor-specific extensions.
\subsubsection{\acrshort{RTPS} Header}
\label{subsubsec:rtps-header}
\textbf{Fields:}
\begin{itemize}
\item \emph{Protocol}
\item \emph{Version}
\item \emph{VendorID}
\item \emph{GUIDPrefix}
\end{itemize}
The fixed-size \emph{\gls{RTPS} Header} must appear at the beginning of every \emph{\gls{RTPS} Message}, and identifies the message as belonging to the \gls{RTPS} protocol.
The \emph{Protocol} field identifies the message as an \emph{\gls{RTPS} Message}, while the \emph{Version} and \emph{VendorID} fields identify the protocol version and the vendor of the implementation that sent the message, respectively.
The \emph{GUIDPrefix} field contains the common \gls{GUID} Prefix that is relevant for all following \emph{\gls{RTPS} Submessages}.
This allows the \emph{\gls{RTPS} Submessages} to contain only the Entity \gls{ID} part of the \gls{GUID}.
\subsubsection{\acrshort{RTPS} Submessage}
\label{subsubsec:rtps-submessage}
Each \emph{\gls{RTPS} Message} consists of a variable number of \emph{\gls{RTPS} Submessages}.
All \emph{\gls{RTPS} Submessages} start with a \hyperref[par:rtps-submessage-header]{\emph{Submessage Header}} part followed by a concatenation of \emph{Submessage Elements}.
The \gls{RTPS} Protocol defines two kinds of \gls{RTPS} Submessages: \hyperref[par:entity-submessages]{Entity-Submessages} and \hyperref[par:interpreter-submessages]{Interpreter-Submessages}.
\emph{Entity-Submessages} target an \emph{\gls{RTPS} Entity}, whereas \emph{Interpreter-Submessages} affect how subsequent \gls{RTPS} Submessages within the same \emph{\gls{RTPS} Message} must be interpreted.
\paragraph{\acrshort{RTPS} Submessage Header}\mbox{}\\
\label{par:rtps-submessage-header}
\textbf{Fields:}
\begin{itemize}
\item \emph{SubmessageID}
\item \emph{Flags}
\item \emph{SubmessageLength}
\end{itemize}
The \emph{SubmessageID} Field identifies the \gls{RTPS} Submessage.
The \emph{Flags} Field contains 8 flags that identify the endianness used to encode the \gls{RTPS} Submessage, the presence of optional elements within the \gls{RTPS} Submessage, and possibly modifies the interpretation of the \gls{RTPS} Submessage.
The \emph{SubmessageLength} Field indicates the length of the Submessage.
This Field can be used to skip to the next \gls{RTPS} Submessage.
In case this Field is zero, the \gls{RTPS} Submessage is the last \gls{RTPS} Submessage in the \gls{RTPS} Message and extends up to the end of the \gls{RTPS} Message.
\paragraph{Entity-Submessages}\mbox{}\\
\label{par:entity-submessages}
Submessages that are optional according to the specification are marked in \textcolor{orange}{orange}.
\begin{description}
\item[DATA]
\textbf{Direction:} \gls{RTPS} Writers to \gls{RTPS} Readers
This \gls{RTPS} Submessage is used to transfer \emph{\gls{RTPS} CacheChanges} from an \gls{RTPS} Writer to \gls{RTPS} Readers.
This \gls{RTPS} Submessage can contain an optional parameter list called \emph{inlineQoS} if the \emph{InlineQOSFlag} is set in the Flags field of the \gls{RTPS} Submessage Header.
If the remote \gls{RTPS} Reader has set the \emph{Expects Inline QoS} attribute, the \gls{RTPS} Writer has to sent all\footnote{A parameter that \emph{should} be in the list, but is missing, assumes the default value.} relevant\footnote{\gls{QOS} marked \textcolor{red}{red} in \cref{Section}{subsec:qos-policies}.} \gls{QOS} inside the \emph{inlineQoS} parameter list, along with the Topic Name\footnote{This makes the DATA Submessage self-describing, and allows \gls{RTPS} Reader implementations to not hold state of remote \gls{RTPS} Writers.}.
Depending on the setting of the \emph{DataFlag} and \emph{KeyFlag} in the Flags field of the \gls{RTPS} Submessage Header, the \gls{RTPS} DATA Submessage may contain normal data (\emph{DataFlag} = 1, \emph{KeyFlag} = 0), the serialized key\footnote{The topic key of the instance.} (\emph{DataFlag} = 0, \emph{KeyFlag} = 1), or no data at all (\emph{DataFlag} = 0, \emph{KeyFlag} = 0).
In the latter case the \emph{inlineQoS} may contain a key hash (see \cref{Section}{par:key-hash}) to still be able to differentiate the topic instance.
%This Submessage notifies the RTPS Reader of a change to a data-object belonging to the RTPS Writer.
%The possible changes include both changes in value, as well as changes to the lifecycle of the data-instance.
\item[\textcolor{orange}{DATA_FRAG}]
\textbf{Direction:} \gls{RTPS} Writers to \gls{RTPS} Readers
This \gls{RTPS} Submessage extends the \emph{DATA} submessage, and allows the \emph{\gls{RTPS} CacheChange} to be fragmented and sent in parts, allowing the protocol to overcome transport message size limitations.
%Equivalent to a \emph{DATA} Submessage, but only contains a part of the new data\footnote{The same Submessage may contain multiple predefined-sized fragments of the data.}.
%This Submessage allows data to be transmitted as multiple fragments to overcome transport message size limitations.
\item[HEARTBEAT]
\textbf{Direction:} \gls{RTPS} Writers to \gls{RTPS} Readers
This \gls{RTPS} Submessage describes the \emph{\gls{RTPS} CacheChanges} that are available in an \gls{RTPS} Writer.\\
The \gls{RTPS} Writer can also request\footnote{The \gls{RTPS} Submessage Header contains a \emph{Final} flag. By not setting the \emph{Final} Flag, a response is expected.\label{footref:final-flag}} an \gls{RTPS} Reader response (\emph{ACKNACK} Submessage) via this \gls{RTPS} Submessage.\\
This \gls{RTPS} Submessage can also contain Writer Group Information\footnote{Information about the \gls{RTPS} Publisher Group the \gls{RTPS} Writer belongs to. This information can be used to implement the \gls{DDS} PRESENTATION \gls{QOS} with access scope \emph{GROUP}.\label{footref:wgi}}.\\
This \gls{RTPS} Submessage is also used for implementing the \gls{DDS} Liveliness \gls{QOS} (see \cref{Section}{par:liveliness}).\\
\item[\textcolor{orange}{HEARTBEAT_FRAG}]
\textbf{Direction:} \gls{RTPS} Writers to \gls{RTPS} Readers
In the case of data fragmentation (\emph{DATA_FRAG} Submessage), this \gls{RTPS} Submessage describes what fragments of an \emph{\gls{RTPS} CacheChange} are available in an \gls{RTPS} Writer.
\item[GAP]
\textbf{Direction:} \gls{RTPS} Writers to \gls{RTPS} Readers
This \gls{RTPS} Submessage indicates that a range of \emph{\gls{RTPS} CacheChanges} is no longer relevant or available to \gls{RTPS} Readers.\\
Similar to the \emph{HEARTBEAT} \gls{RTPS} Submessage, this Submessage can also contain Writer Group Information\footref{footref:wgi}.
%This Submessage indicates to the \gls{RTPS} Reader that a range of sequence numbers is no longer relevant or available.
\item[ACKNACK]
\textbf{Direction:} \gls{RTPS} Readers to \gls{RTPS} Writers
This \gls{RTPS} Submessage is used to communicate the state of an \gls{RTPS} Reader to an \gls{RTPS} Writer, and allows the \gls{RTPS} Reader to inform the \gls{RTPS} Writer about the \emph{\gls{RTPS} CacheChanges} it has received (positive acknowledgment) and which ones it is still missing (negative acknowledgment).\\
The \gls{RTPS} Reader can also request\footref{footref:final-flag} an \gls{RTPS} Writer response (\emph{HEARTBEAT} Submessage) via this \gls{RTPS} Submessage.
\item[\textcolor{orange}{NACK_FRAG}]
\textbf{Direction:} \gls{RTPS} Readers to \gls{RTPS} Writers
In the case of data fragmentation (\emph{DATA_FRAG} Submessage), this \gls{RTPS} Submessage describes what fragments of an \emph{\gls{RTPS} CacheChange} the \gls{RTPS} Reader is still missing (only negative acknowledgment).
\end{description}
\paragraph{Interpreter-Submessages}\mbox{}\\
\label{par:interpreter-submessages}
\begin{description}
\item[INFO_SOURCE]
This \gls{RTPS} Submessage provides information\footnote{Contains the same fields as an \emph{\gls{RTPS} Submessage Header}.} about the source from which subsequent \emph{Entity-Submessages} originated, and is primarily used for relaying \emph{\gls{RTPS} Submessages}.
\item[INFO_DESTINATION]
This \gls{RTPS} Submessage provides information\footnote{Contains a new \emph{\gls{GUID} Prefix}, with which subsequent \gls{RTPS} Submessages construct their \glspl{GUID}.} about the final destination of subsequent \emph{Entity-Submessages}, and is primarily used for relaying \emph{\gls{RTPS} Submessages}.
\item[INFO_REPLY]
This \gls{RTPS} Submessage contains locators that are to be used to reply to subsequent \emph{Entity-Submessages}.
%This Submessage provides information about where to reply in subsequent \emph{Entity-Submessages}.
\item[INFO_TIMESTAMP]
This \gls{RTPS} Submessage provides a source timestamp which applies to subsequent \emph{Entity-Submessages}.
\item[PAD]
This \gls{RTPS} Submessage is used to add padding to an \emph{\gls{RTPS} Message} if needed for memory alignment.
\end{description}
\subsection{\acrshort{RTPS} Behavior}
\label{subsec:rtps-behavior}
Once an \gls{RTPS} Writer has been matched with an \gls{RTPS} Reader, they are both responsible for ensuring that \gls{RTPS} CacheChanges that exist in the \gls{RTPS} Writer’s HistoryCache are propagated to the \gls{RTPS} Reader’s HistoryCache.
The \gls{RTPS} Protocol describes how the matching \gls{RTPS} Writer and Reader pair must behave in order to propagate \gls{RTPS} CacheChange changes in terms of message exchanges using the \gls{RTPS} Messages defined in \cref{Section}{subsec:rtps-message}.
On the other hand the \gls{RTPS} Protocol does not specify the interactions between \gls{DDS} Entities and their corresponding \gls{RTPS} entities.
How exactly a \gls{DDS} Entity interacts with the \gls{RTPS} HistoryCache is implementation specific and not formally modeled.\\
It is important to realize that the \gls{DDS} DataWriter may remove an \gls{RTPS} CacheChange before it has been propagated to one or more of the matched \gls{RTPS} Readers. The \gls{RTPS} Writer is not in control of when an \gls{RTPS} CacheChange is removed from its \gls{RTPS} HistoryCache. It is the responsibility of the \gls{DDS} DataWriter to only remove those \gls{RTPS} CacheChanges that can be removed based on the communication status and the used \gls{QOS}.
\cref{Section}{subsubsec:rtps-rules} defines the rules that all implementations of the \gls{RTPS} Protocol must satisfy in order to be interoperable with other implementations and complaint with the protocol.\\
The rules only apply to messages exchanged between different \gls{RTPS} implementations\footnote{Different VendorID.}, meaning that implementations by the same vendor may opt for a non-compliant implementation or may use a proprietary protocol instead.
%REF: How exactly a DDS Entity interacts with the HistoryCache however, is implementation specific and not formally modeled by the RTPS protocol. Instead, the Behavior Module of the RTPS protocol only specifies how CacheChange changes are transferred from the HistoryCache of the RTPS Writer to the HistoryCache of each matching RTPS Reader.
%REF: For example, it simply assumes a DDS DataWriter adds and removes CacheChange changes to and from its RTPS Writer’s HistoryCache. Changes are added by the DDS DataWriter as part of its write operation and removed when no longer needed. It is important to realize the DDS DataWriter may remove a CacheChange before it has been propagated to one or more of the matched RTPS Reader endpoints. The RTPS Writer is not in control of when a CacheChange is removed from the Writer’s HistoryCache. It is the responsibility of the DDS DataWriter to only remove those CacheChange changes that can be removed based on the communication status and the DDS DataWriter’s QoS.
\subsubsection{Interoperability Rules}
\label{subsubsec:rtps-rules}
\begin{enumerate}
\item All communications must take place using \gls{RTPS} Messages.
\item All implementations must implement the \gls{RTPS} Message Receiver.
The Message Receiver needs to follow following rules:
\begin{enumerate}
\item If the full \gls{RTPS} Submessage Header cannot be read, the rest of the \gls{RTPS} Message is considered invalid.
\item If the \emph{SubmessageLength} field of the Submessage Header is invalid, the rest of the \gls{RTPS} Message is invalid.
\item An \gls{RTPS} Submessage with an unknown \emph{SubmessageID} fild of the \gls{RTPS} Submessage Header must be ignored and parsing must continue with the next \gls{RTPS} Submessage.
\item The receiver of an \gls{RTPS} Submessage should ignore unknown flags in the \emph{Flags} field of the \gls{RTPS} Submessage Header.
\item A valid \emph{SubmessageLength} field of the \gls{RTPS} Submessage Header must always be used to find the next \gls{RTPS} Submessage, even for known \gls{RTPS} Submessages.
\item A known but invalid \gls{RTPS} Submessage invalidates the rest of the \gls{RTPS} Message.
\end{enumerate}
In particular this rule also includes includes proper Message formatting by preceding \emph{Entity-Submessages} with \emph{Interpreter-Submessages} when required for proper interpretation of the former.
\item The timing characteristics of all implementations must be tunable.
\item Implementations must implement the Simple Participant and Endpoint Discovery Protocols (see \cref{Section}{subsubsec:discovery-protocol}).
\item \gls{RTPS} Writers must not send data out-of-order.
\item \gls{RTPS} Writers must include in-line \gls{QOS} values if requested\footnote{\emph{Expects Inline QoS} attribute of the \gls{RTPS} Reader Entity set to true.} by an \gls{RTPS} Reader.
\item \emph{Reliable}\footnote{\emph{Reliability Level} attribute of the \gls{RTPS} Endpoint Entity set to \emph{RELIABLE}.\label{footref:reliable}} \gls{RTPS} Writers must send periodic HEARTBEAT \gls{RTPS} Submessages.
\item \emph{Reliable}\footref{footref:reliable} \gls{RTPS} Writers must eventually respond to the negative acknowledgment of an ACKNACK \gls{RTPS} Submessage.
\item \gls{RTPS} Writers must send HEARTBEAT and GAP \gls{RTPS} Submessages with Writer Group Information\footref{footref:wgi}.
\item \emph{Reliable}\footref{footref:reliable} \gls{RTPS} Readers must respond eventually after receiving a HEARTBEAT \gls{RTPS} Submessage with final flag not set\footref{footref:final-flag}.
\item \emph{Reliable}\footref{footref:reliable} \gls{RTPS} Readers must respond eventually after receiving a HEARTBEAT \gls{RTPS} Submessage that indicates a sample is missing.
\item Once a \emph{Reliable}\footref{footref:reliable} \gls{RTPS} Reader has positively acknowledged a sample using an ACKNACK \gls{RTPS} Submessage, it can no longer negatively acknowledge that same sample.
\item \emph{Reliable}\footref{footref:reliable} \gls{RTPS} Readers can only send an ACKNACK \gls{RTPS} Submessage in response to a HEARTBEAT \gls{RTPS} Submessage.
\end{enumerate}
\subsubsection{Discovery Protocol}
\label{subsubsec:discovery-protocol}
The \gls{RTPS} Specification splits the discovery protocol in two independent protocols:
\begin{description}
\item[\acrfull{PDP}]
Specifies how \emph{\gls{RTPS} Participants} discover each other.
\item[\acrfull{EDP}]
Specifies how \gls{RTPS} Participants exchange information on the \emph{\gls{RTPS} Endpoints} they contain.
\end{description}
Implementations may choose to support multiple \glspl{PDP} and \glspl{EDP}.
The \gls{RTPS} Specification defines the \hyperref[par:spdp]{\acrfull{SPDP}} and \hyperref[par:sedp]{\acrfull{SEDP}}, that have to be provided by all implementations.\\
Remote Participants using an \gls{RTPS} implementation of a different vendor must be contacted using at least the \gls{SPDP} to ensure interoperability. There is no such requirement when the remote Participant uses the same \gls{RTPS} implementation.
However, if two Participants both support another \gls{EDP}, this alternative protocol can be used instead.
\paragraph{\acrfull{SPDP}}\mbox{}\\
\label{par:spdp}
Each \gls{RTPS} Participant creates two built-in \gls{RTPS} Endpoints \emph{SPDPbuiltinparticipantWriter} and \emph{SPDPbuiltinparticipantReader} (see \cref{Section}{subsubsec:built-in-rtps-endpoint}).
The \emph{SPDPbuiltinparticipantWriter} has in its \gls{RTPS} HistoryCache a single sample of type \hyperref[subpar:spdpdiscoveredparticipantdata]{\emph{SPDPdiscoveredParticipantData}} and periodically sends this sample to a pre-configured list of locators to announce the \gls{RTPS} Participant's presence in the network.
The period of the announcement has to be smaller than the \emph{LeaseDuration} the \gls{RTPS} Participant advertises.
If an \gls{RTPS} Participant fails to send another announcement within the \emph{LeaseDuration}, the \gls{RTPS} Participant can be considered gone.
The \hyperref[subpar:spdpdiscoveredparticipantdata]{\emph{SPDPdiscoveredParticipantData}} contains amongst other things the necessary information to initiate \gls{RTPS} Endpoint discovery using a \gls{EDP}.
The \emph{SPDPbuiltinparticipantReader} receives the participant announcements and contains in its \gls{RTPS} HistoryCache all active discovered remote \gls{RTPS} Participants.
\subparagraph{SPDPdiscoveredParticipantData}
\label{subpar:spdpdiscoveredparticipantdata}
The \emph{SPDPdiscoveredParticipantData} is a parameter list containing following attributes:
\begin{itemize}
\item PID_PARTICIPANT_GUID \textbf{[Topic Key]}\\
The \gls{GUID} of the \gls{RTPS} Participant.
All containing \gls{RTPS} Endpoints have the same \gls{GUID} Prefix.
\item PID_USER_DATA\\
Contains the \gls{DDS} USER_DATA \gls{QOS}.
\item PID_DOMAIN_ID\\
Identifies the \gls{DDS} domain of the associated \gls{DDS} DomainParticipant.
\item PID_DOMAIN_TAG\\
In addition to the \emph{Domain \gls{ID}} defined by the \gls{DDS} Specification, the \gls{RTPS} Specification additionally defines a string called \emph{Domain Tag}, that has to match between \gls{RTPS} participants in order for them to match. This allows sub-segmentation of the \emph{Domain \gls{ID}} space.
\item PID_PROTOCOL_VERSION\\
Identifies the \gls{RTPS} protocol version used by the \gls{RTPS} Participant.
\item PID_VENDORID\\
Identifies the vendor of the implementation of the \gls{RTPS} Participant.
\item PID_EXPECTS_INLINE_QOS\\
Describes wether the \gls{RTPS} Readers within the \gls{RTPS} Participant expect the DATA (or DATA_FRAG) \gls{RTPS} Submessages to contain \emph{inlineQoS}.
\item PID_METATRAFFIC_UNICAST_LOCATOR
\item PID_METATRAFFIC_MULTICAST_LOCATOR\\
List of unicast and multicast locators, respectively, that can be used to send messages to the built-in \gls{RTPS} Endpoints contained in the \gls{RTPS} Participant.
\item PID_DEFAULT__UNICAST_LOCATOR
\item PID_DEFAULT__MULTICAST_LOCATOR\\
Default list of unicast and multicast locators, respectively, that can be used to send messages to the user-defined \gls{RTPS} Endpoints contained in the \gls{RTPS} Participant.
These are the locators that will be used in case the \gls{RTPS} Endpoint does not specify its own set of locators.
\item PID_BUILTIN_ENDPOINT_SET\\
Identifies what built-in \gls{RTPS} Endpoints are available on the \gls{RTPS} Participant.
\item PID_PARTICIPANT_MANUAL_LIVELINESS_COUNT\\
Contains the count of liveliness assertions when using \gls{DDS} LIVELINESS \gls{QOS} MANUAL_BY_PARTICIPANT.
\item PID_BUILTIN_ENDPOINT_QOS\\
Contains additional information on the \gls{QOS} of the built-in \gls{RTPS} Endpoints supported by the \gls{RTPS} Participant\footnote{Currently contains only information if the \emph{BuiltinParticipantMessageReader} has reliability BEST_EFFORT.}.
\item PID_PARTICIPANT_LEASE_DURATION\\
Contains the duration for which an \gls{RTPS} Participant should be considered alive every time an announcement is received from the \gls{RTPS} Participant.
\end{itemize}
\paragraph{\acrfull{SEDP}}\mbox{}\\
\label{par:sedp}
The \gls{SEDP} uses the built-in \gls{RTPS} Endpoints \emph{SEDPbuiltinPublicationsWriter}, \emph{SEDPbuiltinPublicationsReader}, \emph{SEDPbuiltinSubscriptionsWriter}, \emph{SEDPbuiltinSubscriptionsReader}, \emph{SEDPbuiltinTopicsWriter}, and \emph{SEDPbuiltinTopicsReader} (see \cref{Section}{subsubsec:built-in-rtps-endpoint}) to exchange information about the contained \gls{RTPS} Readers and Writers, and available \gls{DDS} Topics.
Implementations are not required to provide all built-in \gls{RTPS} Endpoints.
More specifically \gls{DDS} Topic propagation is optional, and \gls{RTPS} Participant are only required to provide the built-in Endpoints required for matching up local and remote Endpoints\footnote{If an \gls{RTPS} Participant will only contain \gls{RTPS} Writers, the only required \gls{RTPS} built-in Endpoints are the \emph{SEDPbuiltinPublicationsWriter} and the \emph{SEDPbuiltinSubscriptionsReader}.}.
Whereas the \gls{SPDP} uses reliability level BEST_EFFORT and relies on the periodic (re-)sending of data by the \gls{RTPS} Writers, the \gls{SEDP} uses reliability level RELIABLE and uses the same communication schema as for user-defined \gls{RTPS} Endpoints described in previous sections.\\
The \gls{RTPS} HistoryCaches of the \emph{SEDPbuiltinPublicationsWriter}, \emph{SEDPbuiltinSubscriptionsWriter}, and \emph{SEDPbuiltinTopicsWriter} contain samples of type \hyperref[subpar:discoveredwriterdata]{\emph{DiscoveredWriterData}}, \hyperref[subpar:discoveredreaderdata]{\emph{DiscoveredReaderData}}, and \hyperref[subpar:discoveredtopicdata]{\emph{DiscoveredTopicData}} equal to the number of \gls{RTPS} Writers, \gls{RTPS} Readers, and \gls{DDS} Topics of the \gls{RTPS} Participant, respectively.
\subparagraph{DiscoveredWriterData}
\label{subpar:discoveredwriterdata}
The \emph{DiscoveredWriterData} is a parameter list containing following attributes:
\begin{itemize}
\item PID_ENDPOINT_GUID \textbf{[Topic Key]}\\
The \gls{GUID} of the \gls{RTPS} Writer.
\item PID_PARTICIPANT_GUID\\
The \gls{GUID} of the \gls{RTPS} Participant containing the \gls{RTPS} Writer.
\item PID_TOPIC_NAME\\
String containing the name of the \gls{DDS} Topic. Has to be equal in order for \gls{RTPS} Endpoints to match.
\item PID_TYPE_NAME\\
String containing the name of the data type used for the topic. Has to be equal in order for \gls{RTPS} Endpoints to match.
\item PID_USER_DATA\\
\gls{DDS} USER_DATA \gls{QOS}\footnote{See \cref{Section}{subsec:qos-policies}.\label{footref:qos}}.
\item PID_TOPIC_DATA\\
\gls{DDS} TOPIC_DATA \gls{QOS}\footref{footref:qos}.
\item PID_GROUP_DATA\\
\gls{DDS} GROUP_DATA \gls{QOS}\footref{footref:qos}.
\item PID_DURABILITY\\
\gls{DDS} DURABILITY \gls{QOS}\footref{footref:qos}.
\item PID_DURABILITY_SERVICE\\
\gls{DDS} DURABILITY_SERVICE \gls{QOS}\footref{footref:qos}.
\item PID_PRESENTATION\\
\gls{DDS} PRESENTATION \gls{QOS}\footref{footref:qos}.
\item PID_DEADLINE\\
\gls{DDS} DEADLINE \gls{QOS}\footref{footref:qos}.
\item PID_LATENCY_BUDGET\\
\gls{DDS} LATENCY_BUDGET \gls{QOS}\footref{footref:qos}.
\item PID_OWNERSHIP\\
\gls{DDS} OWNERSHIP \gls{QOS}\footref{footref:qos}.
\item PID_OWNERSHIP_STRENGTH\\
\gls{DDS} OWNERSHIP_STRENGTH \gls{QOS}\footref{footref:qos}.
\item PID_LIVELINESS\\
\gls{DDS} LIVELINESS \gls{QOS}\footref{footref:qos}.
\item PID_PARTITION\\
\gls{DDS} PARTITION \gls{QOS}\footref{footref:qos}.
\item PID_RELIABILITY\\
\gls{DDS} RELIABILITY \gls{QOS}\footref{footref:qos}.
\item PID_LIFESPAN\\
\gls{DDS} LIFESPAN \gls{QOS}\footref{footref:qos}.
\item PID_DESTINATION_ORDER\\
\gls{DDS} DESTINATION_ORDER \gls{QOS}\footref{footref:qos}.
\item PID_UNICAST_LOCATOR\\
Unicast locators to be used to send messages the \gls{RTPS} Writer.
\item PID_MULTICAST_LOCATOR\\
Multicast locators to be used to send messages the \gls{RTPS} Writer.
\item PID_TYPE_MAX_SIZE_SERIALIZED\\
\emph{Data Max Size Serialized} attribute of the \gls{RTPS} Writer\footnote{See \cref{Section}{subsubsec:rtps-writer}.}.
\end{itemize}
\subparagraph{DiscoveredReaderData}
\label{subpar:discoveredreaderdata}
The \emph{DiscoveredReaderData} is a parameter list containing following attributes:
\begin{itemize}
\item PID_ENDPOINT_GUID \textbf{[Topic Key]}\\
The \gls{GUID} of the \gls{RTPS} Reader.
\item PID_PARTICIPANT_GUID\\
The \gls{GUID} of the \gls{RTPS} Participant containing the \gls{RTPS} Reader.
\item PID_TOPIC_NAME\\
String containing the name of the \gls{DDS} Topic. Has to be equal in order for \gls{RTPS} Endpoints to match.
\item PID_TYPE_NAME\\
String containing the name of the data type used for the topic. Has to be equal in order for \gls{RTPS} Endpoints to match.
\item PID_USER_DATA\\
\gls{DDS} USER_DATA \gls{QOS}\footref{footref:qos}.
\item PID_TOPIC_DATA\\
\gls{DDS} TOPIC_DATA \gls{QOS}\footref{footref:qos}.
\item PID_GROUP_DATA\\
\gls{DDS} GROUP_DATA \gls{QOS}\footref{footref:qos}.
\item PID_DURABILITY\\
\gls{DDS} DURABILITY \gls{QOS}\footref{footref:qos}.
\item PID_PRESENTATION\\
\gls{DDS} PRESENTATION \gls{QOS}\footref{footref:qos}.
\item PID_DEADLINE\\
\gls{DDS} DEADLINE \gls{QOS}\footref{footref:qos}.
\item PID_LATENCY_BUDGET\\
\gls{DDS} LATENCY_BUDGET \gls{QOS}\footref{footref:qos}.
\item PID_OWNERSHIP\\
\gls{DDS} OWNERSHIP \gls{QOS}\footref{footref:qos}.
\item PID_LIVELINESS\\
\gls{DDS} LIVELINESS \gls{QOS}\footref{footref:qos}.
\item PID_TIME_BASED_FILTER\\
\gls{DDS} TIME_BASED_FILTER \gls{QOS}\footref{footref:qos}.
\item PID_PARTITION\\
\gls{DDS} PARTITION \gls{QOS}\footref{footref:qos}.
\item PID_RELIABILITY\\
\gls{DDS} RELIABILITY \gls{QOS}\footref{footref:qos}.
\item PID_DESTINATION_ORDER\\
\gls{DDS} DESTINATION_ORDER \gls{QOS}\footref{footref:qos}.
\item PID_UNICAST_LOCATOR\\
Unicast locators to be used to send messages the \gls{RTPS} Reader.
\item PID_MULTICAST_LOCATOR\\
Multicast locators to be used to send messages the \gls{RTPS} Reader.
\item PID_EXPECTS_INLINE_QOS\\
\emph{Expect Inline QoS} attribute of the \gls{RTPS} Reader\footnote{See \cref{Section}{subsubsec:rtps-reader}.}.
\item PID_CONTENT_FILTER_INFO\\
See \cref{Section}{par:content-filtered-topics}.
\end{itemize}
\subparagraph{DiscoveredTopicData}
\label{subpar:discoveredtopicdata}
The \emph{DiscoveredTopicData} is a parameter list containing following attributes:
\begin{itemize}
\item PID_ENDPOINT_GUID\\
The \gls{GUID} used to uniquely identify the \gls{DDS} Topic. The \gls{RTPS} Specification does not specify how the \gls{GUID} is selected.
\item PID_TOPIC_NAME\\
String containing the name of the \gls{DDS} Topic.
\item PID_TYPE_NAME\\
String containing the name of the data type used for the topic.
\item PID_TOPIC_DATA\\
\gls{DDS} TOPIC_DATA \gls{QOS}\footref{footref:qos}.
\item PID_DURABILITY\\
\gls{DDS} DURABILITY \gls{QOS}\footref{footref:qos}.
\item PID_DURABILITY_SERVICE\\
\gls{DDS} DURABILITY_SERVICE \gls{QOS}\footref{footref:qos}.
\item PID_DEADLINE\\
\gls{DDS} DEADLINE \gls{QOS}\footref{footref:qos}.
\item PID_LATENCY_BUDGET\\
\gls{DDS} LATENCY_BUDGET \gls{QOS}\footref{footref:qos}.
\item PID_OWNERSHIP\\
\gls{DDS} OWNERSHIP \gls{QOS}\footref{footref:qos}.
\item PID_LIVELINESS\\
\gls{DDS} LIVELINESS \gls{QOS}\footref{footref:qos}.
\item PID_RELIABILITY\\
\gls{DDS} RELIABILITY \gls{QOS}\footref{footref:qos}.
\item PID_TRANSPORT_PRIORITY\\
\gls{DDS} TRANSPORT_PRIORITY \gls{QOS}\footref{footref:qos}.
\item PID_LIFESPAN\\
\gls{DDS} LIFESPAN \gls{QOS}\footref{footref:qos}.
\item PID_DESTINATION_ORDER\\
\gls{DDS} DESTINATION_ORDER \gls{QOS}\footref{footref:qos}.
\item PID_HISTORY\\
\gls{DDS} HISTORY \gls{QOS}\footref{footref:qos}.
\item PID_RESOURCE_LIMITS\\
\gls{DDS} RESOURCE_LIMITS \gls{QOS}\footref{footref:qos}.
\end{itemize}
\subsubsection{\acrshort{DDS} in \acrshort{RTPS}}
\label{subsubsec:dds-in-rtps}
This Section defines the extensions needed for the \gls{RTPS} Protocol to support some \gls{DDS} \gls{QOS} and features.
\paragraph{PRESENTATION \gls{QOS}}\mbox{}\\
\label{par:presentation}
\subparagraph{GROUP Ordered Access}\mbox{}\\
The \gls{RTPS} Specification extends the \emph{inlineQoS} parameter list of the DATA (and DATA_FRAG) \gls{RTPS} Submessage to convey additional information, that denotes ordering within the scope of the \gls{RTPS} Publisher, as well as the identity of the \gls{RTPS} Writers belonging to the \gls{RTPS} Publisher.\\
Following parameters convey this information:
\begin{description}
\item[PID_GROUP_SEQ_NUM]
Contains the \emph{Group Sequence Number}, a strictly monotonically increasing sequence number that is incremented every time an \gls{RTPS} Writer attached to the same \gls{RTPS} Publisher Group increments his own sequence number.
\item[PID_WRITER_GROUP_INFO]
Contains a Group Digest that identifies the set of \gls{RTPS} Writer Entity \glspl{ID} that are announced in the \emph{DiscoveredWriterData}\footnote{see \cref{Section}{subpar:discoveredwriterdata}.} that belonged to the \gls{RTPS} Publisher at the time the sample was written.
\end{description}
The above information allows an \gls{RTPS} Subscriber Group to order the samples received by its \gls{RTPS} Readers according to the Group Sequence Number of the remote \gls{RTPS} Publisher Group.
\subparagraph{Coherent Access}\mbox{}\\
The \gls{DDS} specification provides the functionality to define a set of sample updates as a coherent set. A \gls{DDS} DataReader is only notified of the arrival of new updates once all updates in the coherent set have been received.
A \emph{Publisher Coherent Set} is defined as the set of all \gls{RTPS} CacheChanges performed by all \gls{DDS} DataWriters in the \gls{DDS} Publisher delimited by the operations \texttt{begin_coherent_changes()} and \texttt{end_coherent_changes()}.
A \emph{Subscriber Coherent Set} is a subset of the \emph{Publisher Coherent Set} that the Subscriber must receive in order to consider the coherent set complete.
The \emph{Subscriber Coherent Set} depends on the configured \emph{access_scope} of the PRESENTATION \gls{DDS} \gls{QOS} and the removing of irrelevant\footnote{\gls{RTPS} CacheChanges from unmatched \gls{RTPS} Writers or \gls{RTPS} CacheChanges filtered by content or time.} \gls{RTPS} CacheChanges.
The \gls{RTPS} Specification extends the \emph{inlineQoS} parameter list of the DATA (and DATA_FRAG) \gls{RTPS} Submessage to convey additional information, that denotes membership to a particular coherent set.\\
Following parameters convey this information:
\begin{description}
\item[PID_COHERENT_SET]
Contains the sequence number of the first \gls{RTPS} CacheChange belonging to the coherent set from the \gls{RTPS} Writer.
\item[PID_GROUP_COHERENT_SET\footnote{Used only by \gls{DDS} \gls{QOS} PRESENTATION with \emph{access_scope}=GROUP.}]
Contains the group sequence number of the first \gls{RTPS} CacheChange belonging to the coherent set across all \gls{RTPS} Writer within the \gls{RTPS} Publisher Group.
\end{description}
For \gls{DDS} \gls{QOS} PRESENTATION with access_scope $\neq$ GROUP, the end of a coherent set is defined by the arrival of an \gls{RTPS} DATA (or DATA_FRAG) Submessage with a different\footnote{The special value \emph{SEQUENCENUMBER_UNKNOWN} is also allowed.} sequence number in \emph{PID_COHERENT_SET}.
For \gls{DDS} \gls{QOS} PRESENTATION with access_scope = GROUP, the end of a coherent set is defined by the arrival of an \emph{\gls{ECS}} Submessage, which is sent by \emph{all} \gls{RTPS} Writers of an \gls{RTPS} Publisher Group.\\
An \gls{ECS} Submessage is a DATA (or DATA_FRAG) Submessage with no data payload, \emph{PID_GROUP_SEQ_NUM} equal to one greater than the group sequence number of the final \gls{RTPS} CacheChange in the group coherent set, \emph{PID_GROUP_COHERENT_SET} equal to the sequence number of the coherent set that it marks the end of, and \emph{PID_GROUP_WRITER_INFO} set to encode which \gls{RTPS} Writers were contained in the \gls{RTPS} Publisher Group during the time that the coherent set was written.\\
The \gls{ECS} cannot be filtered and can only be removed from the \gls{RTPS} Writer HistoryCache when all \gls{RTPS} CacheChanges belonging to the coherent set are removed.
\paragraph{LIVELINESS \gls{QOS}}\mbox{}\\
\label{par:liveliness}
The \gls{RTPS} Specification defines the \emph{Writer Liveliness Protocol}, which defines the required information exchange between two \gls{RTPS} Participants in order to assert the liveliness of \gls{RTPS} Writers contained by the \gls{RTPS} Participants.
The \emph{Writer Liveliness Protocol} uses the \emph{BuiltinParticipantMessageWriter} and \emph{BuiltinParticipantMessageReader} built-in \gls{RTPS} Endpoints defined in \cref{Section}{subsubsec:built-in-rtps-endpoint}.
\subparagraph{AUTOMATIC LIVELINESS}\mbox{}\\
For AUTOMATIC liveliness the \gls{RTPS} Participant sends a \emph{ParticipantMessageData} with the kind field set to \emph{AUTOMATIC_LIVELINESS_UPDATE} to refresh the liveliness of all contained \gls{RTPS} Writers with LIVELINESS \gls{QOS} set to AUTOMATIC.
The \gls{RTPS} Participant has to send a sample faster than the smallest lease duration among the respective \gls{RTPS} Writers.
\subparagraph{MANUAL_BY_PARTICIPANT LIVELINESS}\mbox{}\\
For MANUAL_BY_PARTICIPANT liveliness the \gls{RTPS} Participant checks periodically to see if any of the contained \gls{RTPS} Writers with LIVELINESS \gls{QOS} set to MANUAL_BY_PARTICIPANT has asserted its liveliness\footnote{By calling the \texttt{write()}, \texttt{assert_liveliness()}, \texttt{dispose()}, or \texttt{unregister_instance()} \gls{DDS} Operations.}, and if so, sends a \emph{ParticipantMessageData} with the kind field set to \emph{MANUAL_LIVELINESS_UPDATE} to refresh the liveliness of the respective \gls{RTPS} Writers.
The period for this check has to be the smaller than the smallest lease duration among the respective \gls{RTPS} Writers.
\subparagraph{MANUAL_BY_TOPIC LIVELINESS}\mbox{}\\
For MANUAL_BY_PARTICIPANT liveliness the \gls{RTPS} Writer itself is responsible for refreshing his liveliness by sending a DATA (or DATA_FRAG) \gls{RTPS} Submessage, or a HEARTBEAT \gls{RTPS} Submessage with the \emph{liveliness} flag set in the Flag field of the \gls{RTPS} Submessage Header.
\paragraph{Content-Filtered Topics}\mbox{}\\
\label{par:content-filtered-topics}
The \gls{DDS} Specification defines \emph{Content-Filtered Topics}, that can be used as content-based subscription by allowing the subscriber to specify with filer expressions the content that is of interest.
When filtering on the subscriber side, the \gls{RTPS} protocol is not directly involved.
On the other hand when filtering on the publisher side, which may improve performance by reducing network traffic, extensions to the \gls{RTPS} protocol are required.\\
Publisher-side filtering is optional.
The subscriber-side filter information has to be propagated to the publisher side for publisher-side filtering.
This happens by extending the \emph{DiscoveredReaderData} type (see \cref{Section}{subpar:discoveredreaderdata}) exchanged during the Discovery Protocol by following parameter:
\begin{description}
\item[PID_CONTENT_FILTER_PROPERTY]
This parameter is a struct of following attributes:
\begin{itemize}
\item \emph{ContentFilteredTopicName}\\
Name of the Content-filtered Topic associated with the \gls{RTPS} Reader.
\item \emph{RelatedTopicName}\\
Name of the Topic related to the Content-filtered Topic.
\item \emph{FilterClassName}\\
Identifies the filter class this filter belongs to. \gls{RTPS} defines the \emph{DDSSQL} filter class, which is the SQL filter specified by the \gls{DDS} Specification and has to be available in all implementations.
\item \emph{FilterExpression}\\
The actual filter expression.
\item \emph{ExpressionParameters}\\
Defines the value for each parameter in the filter expression.
\end{itemize}
\end{description}
In case a sample does not pass any of the filters of the matched \gls{RTPS} Readers, the \gls{RTPS} Writer replaces the \gls{RTPS} DATA (of DATA_FRAG) Submessage with a GAP Submessage or a special instance state transition (see \cref{Section}{par:instance-state-transition}).\\
Alternatively the \gls{RTPS} DATA (of DATA_FRAG) Submessage has to be sent, but include information on what filters were applied (and wether they passed the filter) on the publisher-side, so that the \gls{RTPS} Readers may discard the samples if their filter was applied.
This information is conveyed by extending the \emph{inlineQoS} parameter list with following parameter:
\begin{description}
\item[PID_CONTENT_FILTER_INFO]
This parameter is a struct of following attributes:
\begin{itemize}
\item \emph{FilterSignatures}\\
A list of \emph{FilterSignatures} that were applied to the sample.
A \emph{FilterSignature} uniquely identifies a filter and is based on the content of the \emph{PID_CONTENT_FILTER_PROPERTY} parameter.
\item \emph{FilterResult}\\
For each \emph{FilterSiganture}, the results indicate whether the sample passed the filter.
\end{itemize}
\end{description}
\paragraph{Instance State Change}\mbox{}\\
\label{par:instance-state-transition}
As explained in \cref{Section}{subsec:dcps-model} the \gls{DDS} Specification defines instance states \emph{ALIVE}, \emph{NOT_ALIVE_DISPOSED}, and \emph{NOT_ALIVE_NO_WRITERS}.
In order for the \gls{DDS} DataReader to correctly transition between these states, additional information has to be conveyed by the \gls{RTPS} Protocol.\\
The \gls{RTPS} Protocol defines following instance statuses that convey the needed information:
\begin{description}
\item[ALIVE]
Instance state taken whenever a new sample is written on the instance.
\item[ALIVE_FILTERED]
Instance state taken whenever a new sample is written on the instance, but the sample does not pass the filter of the subscriber.\footnote{If the previous instance-sample was also filtered, the sender may omit sending the status again. This implies instance state keeping of remote receivers.}
\item[NOT_ALIVE_DISPOSED]
Instance state taken whenever the DataWriter disposes the instance.
\item[NOT_ALIVE_UNREGISTERED]
Instance state taken whenever the DataWriter unregisters the instance.
\end{description}
These instance statuses are conveyed by extending the \emph{inlineQoS} parameter list of \gls{RTPS} DATA (or DATA_FRAG) Submessages with following parameter:
\begin{description}
\item[PID_STATUS_INFO]
Contains flags differentiating between the ALIVE, ALIVE_FILTERED, NOT_ALIVE_DISPOSED, and NOT_ALIVE_UNREGISTERED statuses.
\end{description}
\paragraph{Original Writer Info}\mbox{}\\
\label{par:original-writer-info}
In order to implement the \gls{DDS} \emph{Transient} and \emph{Persistent} Durability \gls{QOS}, there is the need to send data on behalf of another writer.
The \gls{RTPS} Specification supports this forwarding of messages by including information of the original writer.
This information is conveyed by extending the \emph{inlineQoS} parameter list of \gls{RTPS} DATA (or DATA_FRAG) Submessages with following parameter:
\begin{description}
\item[PID_ORIGINAL_WRITER_INFO]
This parameter is a struct of following attributes:
\begin{itemize}
\item \emph{OriginalWriterGUID}\\
The \gls{GUID} of the \gls{RTPS} Writer that first generated the message.
\item \emph{OriginalWriterSN}\\
The sequence number of the \gls{RTPS} CacheChange as sent from the original \gls{RTPS} Writer.
\end{itemize}
\end{description}
The receiving \gls{RTPS} Reader will store the \gls{RTPS} CacheChange as coming from the \gls{RTPS} Writer indicated in the \emph{OriginalWriterGUID} attribute\footnote{Assuming the original Writer would match this Reader, which should be the case if the Reader matched the Writer of the durability service.}, and store it with the sequence number indicated by the \emph{OriginalWriterSN} attribute.
\paragraph{Key Hash}\mbox{}\\
\label{par:key-hash}
The \gls{RTPS} Specification defines a hash calculation on the topic key, to allow arbitrary length topic keys to be mapped to a standard key hash length.
Sending this pre-calculated key hash together with the data may increase performance by preventing the receiver from having to de-serialize the key from the data.
The key hash is sent by extending the \emph{inlineQoS} parameter list of \gls{RTPS} DATA (or DATA_FRAG) Submessages with following parameter:
\begin{description}
\item[PID_KEY_HASH]
Contains the key hash that uniquely identifies the topic instance.
\end{description}
% Mention directed write and PID_DIRECTED_WRITE?
% To be honest, I don't even understand the use case of this parameter.
\chapter{Related Work}
\label{ch:related-work}
Besides closed-source, commercial, and proprietary solutions like \cite{rtps-nic}, no open-source hardware implementations (or accelerations) of the \gls{RTPS}/\gls{DDS} standards are known.
\gls{OMG} has also released a \gls{DDS-XRCE} specification, which defines a protocol between an \gls{XRCE} Client and an \gls{XRCE} Agent.
The cut-down requirements of the protocol allow the \gls{XRCE} Client to be implemented in devices with limited resources and connectivity options.
The \gls{XRCE} Agent is a full-fledged \gls{DDS} participant and acts as a proxy between \gls{XRCE} Clients and other \gls{DDS} Participants.
Since 2015\footnote{The year of the first publication I could find relating to hardware acceleration in \glspl{FPGA} of \gls{ROS} components.} there is an ever growing interest in facilitating hardware acceleration in \gls{ROS} systems.\\
The \emph{micro-ROS} framework\cite{micro-ros} uses the \gls{DDS-XRCE} protocol to integrate \gls{ROS} 2 into microcontrollers.
A possible way to integrate \gls{ROS} in \glspl{FPGA} would be to instantiate a soft-core processor (like MicroBlaze or NIOS II) and run micro-ROS on top.\\
On the other hand, the rise of programmable \glspl{SOC} with their tight coupling of \gls{PS} and \gls{PL} sides, allows users to easily offload compute intensive parts of a software stack and accelerate them in an \gls{FPGA}.
There have been many works\cite{simple-1, simple-2, simple-3, simple-4, simple-5, simple-6, simple-7} that use this principle of having \gls{ROS} running on top of a fully-fledged Linux distribution in the \gls{PS} side\footnote{Note that \cite{simple-5} is not using a programmable \gls{SOC}, but a Raspberry Pi3 intercommunicating via a custom \gls{GPIO} bus with a DE0-Nano \gls{FPGA} board.}, while certain parts of \gls{ROS} nodes are offloaded and accelerated in the \gls{PL} side.\\
The research community is acknowledging that the main users of \gls{ROS} are roboticists, which on average do not have the required hardware engineering skills to directly program an \gls{FPGA}.
Thus many works try to make accelerating \gls{ROS} components more abstract and accessible, and integrate them to common \gls{ROS} development flows.\\
This section focuses on works that integrate \gls{ROS} elements themselves in hardware, and not only application code running on top of \gls{ROS}.
\section{ROS-Compliant FPGA Components}
\label{sec:ros-compliant-fpga-components}
\glsreset{CRECOMP}
In 2015 Yamashina et al. \cite{rcfc} (see also \cite{rcfc-2}) proposed \emph{ROS-Compliant FPGA Components}, which they define as having following requirements:
\begin{itemize}
\item The functionality of the \gls{ROS}-compliant \gls{FPGA} component is equivalent to that implemented in software.
\item The message type and data format used at the input and output of the \gls{ROS}-compliant \gls{FPGA} component is equivalent to that implemented in software.
\end{itemize}
Then they propose a \emph{ROS-compliant FPGA component model}, which has one \gls{ROS} subscriber (Input) and \gls{ROS} publisher (Output) in the \gls{PS} side, and the actual acceleration kernel in the \gls{PL} side\footnote{Note that this implies a programmable \gls{SOC} with integrated processor and \gls{FPGA}.}. The acceleration kernel communicates with the \gls{ROS} nodes in the \gls{PS} side via \gls{FIFO} Buffers.\\
A case study accelerating image labeling on a ZedBoard\footnote{Xilinx Zynq-7000 XC7Z020-CLG484-1.\label{footref:zedboard}} using Xilinux in the \gls{PS} side and Xilibus for \gls{PS}-\gls{PL} communication achieved a 170\% (1.7x) speedup (against a software only solution running on the \gls{PS} side of the ZedBoard).
In 2016 Yamashina et al. \cite{crecomp} (see also \cite{crecomp-2}) acknowledge the high development cost of \gls{HDL}-based circuitry, and design an automated design tool called \emph{\gls{CRECOMP}}, that automatically generates the \gls{PS}-\gls{PL} interface files required for the ROS-compliant FPGA component model based on a configuration file that describes the acceleration kernel.\\
An evaluation was made on a group of six novice developers, showing that the tool could be successfully used in under an hour. Unfortunately the evaluation did not include a control group, thus failing to show the actual development improvement the tool provides.
On the original proposal \cite{rcfc} the authors acknowledge a large \gls{ROS} communication overhead.
In 2017 Sugata et al. \cite{rcfc2} try to reduce this overhead by moving part of the \gls{ROS} communication into hardware.
More specifically the direct peer-to-peer communication of \gls{ROS} 1 (TCPROS) is implemented in the \gls{FPGA} using the SiTCP \cite{sitcp} \gls{TCP}/\gls{IP} hardware stack.
The communication with the \gls{ROS} master (\gls{XML-RPC}) is still handled in software on the \gls{PS} side.
An evaluation on the exTri-CSI\footnote{Xilinx Spartan-6 XC6SLX100.}\footnote{Note that this board has no processor. The \gls{IP} Address/Port usually communicated via the \gls{XML-RPC} protocol is provided via the \gls{UDP} control port of the SiTCP stack.} board showed a 50\% (0.5x) reduction in latency compared to a software only approach running on the \gls{PS} side of a ZedBoard\footref{footref:zedboard}.
It has to be noted that no actual acceleration kernel is used and the messages are only replayed from the subscribing to the publishing side, hence there is no difference between a software only \gls{ROS} node, and the \emph{ROS-compliant FPGA component model} proposed in \cite{rcfc}.
In 2019 Ohkawa et al. \cite{rcfc3} propose a \gls{HLS} design flow, where the hardware publisher and subscriber presented previously, including the conversion to/from \gls{ROS} message format, is generated as \gls{HLL} (C/C++) based on a \gls{ROS} message definition, and a \gls{ROS} node config file. This \gls{HLL} output can be used together with the actual user application in \gls{HLS} to generate the actual bitstream for the \gls{FPGA}.
A feasibility evaluation was made, where a \gls{HLL} design was hand written and was found to need only 127 lines of code (instead of the 860 lines of code using traditional \gls{HDL}), which the authors claim that indicates improvement in productivity.
\section{\acrshort{FOREST}}
\label{sec:forest}
In 2020 Leal et al. \cite{forest} present their open-source tool called \emph{\acrfull{FOREST}}. Similar to \gls{CRECOMP} for \gls{ROS} 1, \gls{FOREST} generates \gls{HLL} \gls{ROS} 2 code for \gls{HLS} using PYNQ\cite{pynq}\footnote{Note that this implies that \gls{FOREST} is only supported on boards supported by PYNQ.} drivers based on a configuration file.
That also means that similar to the \emph{ROS-Compliant FPGA Components model} the \gls{PS} side contains the actual \gls{ROS} communication nodes, and a translation/communication driver (in this case PYNQ) is used to communicate with the actual acceleration kernel running on the \gls{PL} side.
A case study accelerating linear contrast stretching on a Zybo\footnote{Xilinx Zynq-7000 XC7Z010-1CLG400C.} board achieved 5828\% (58.28x) speedup\footnote{Comprised of a 248.8x speedup of the algorithm, and a 0.1x higher \gls{ROS} 2 communication overhead.} compared to a software only solution running on the \gls{PS} side of the Zybo board.
Further case studies evaluating the use of \gls{FOREST} can be found in \cite{forest2} and \cite{forest3}.
Note that the last evaluation in \cite{forest3} actually shows a significant \gls{PS}-\gls{PL} communication overhead, that make the actual \gls{FPGA} solution slower.
%REF: Even though they target ROS2, they use .msg and nothing precisely from ROS2 (such as the subset of OMG IDL specification 2 ). However, both ROS versions support .msg (with minor changes), and their approach is valid. They claim to support multiple data types. However, messages could be formed by variables of different data types or multiple nested messages which they seem to ignore as there is only support for (arrays of) primitive types.
\section{Reconfigurable Computing System Architecture for Robotic Applications}
\label{sec:reconfigurable-computing-system-architecture-for-robotic-applications}
In 2019 Podlubne et al. \cite{fpga-ros} propose a methodology to design a \emph{Modular Architecture for \gls{ROS}-Compatible\footnote{\gls{ROS} 1.} Reconfigurable Applications}.
By design each user application has to have an \gls{HDL} port layout that can directly map to the used \gls{ROS} message layout.
A \emph{Standard IP to AXIS Frame Converter} serializes/deserializes the ports to/from \gls{AXIS} frames.
Multiple user applications could be instantiated along with their respective \emph{Standard IP to AXIS Frame Converters}, and multiplexed together, managed by a \emph{Manager}.
A \emph{Protocol Generator} converts the \gls{AXIS} Frames to/from a \gls{ROS} compatible wire format before/after coming/going to the \emph{\gls{TCP}/\gls{IP} Interface}.
The \emph{Manager} is also responsible for the communication with the \gls{ROS} master via direct interaction with the \emph{\gls{TCP}/\gls{IP} Interface}.\\
Although all components are thought to be placed in hardware, the \emph{Protocol Generator}, \emph{\gls{TCP}/\gls{IP} Interface}, and \emph{Manager} block can also be placed in the \gls{PS} side (or externally).
%REF: We previously proposed in [24] a generic architecture to have a full hardware implementation without the need of any CPU. It is generic so that it can incorporate IPs designed in HDL or HLS. Moreover, it leaves the possibility to replace the communication block if a different device is used, or communications are handled by a CPU if available or desired. In case a different middleware rather than ROS is needed, the modular architecture allows to replace the specific-related middleware IP block thanks to the plug&play design. Lastly, it opens the possibility for robotic applications to use Dynamic Partial Reconfiguration (DPR), which can use the same hardware resources to implement different steps of a time-multiplexed algorithm. Consequently, the flexibility and power efficiency would be enhanced as well [19]. However, there was not a systematic approach to map complete ROS messages to hardware, which is addressed in this work.
In 2021 Podlubne et al. \cite{fpga-ros2} extend upon this work, but switched to a model-based approach, which allows them to abstract from the used middleware, hardware target, and their respective tools.\\
In terms of the architecture model, the \emph{Standard IP to AXIS Frame Converter} was split into \emph{Standard IP to AXIS Frame Converter} and \emph{AXIS Frame to Standard IP Converter}, depending on if they are connected to a publisher or subscriber, respectively.
The functionality of the \emph{Protocol Generator} was merged into the \emph{Manager} block, and the \emph{\gls{TCP}/\gls{IP} Interface} block was renamed to \emph{Communication Interface}.\\
An open-source toolchain was published, able to generate \gls{VHDL} code from a simple system specification.
The robustness of the toolchain towards complex \gls{ROS} message definitions is validated through an evaluation of all 2295 \gls{ROS} message specifications included in the last \gls{ROS} 1 version\footnote{Noetic Ninjemys.}.
The toolchain was also extended to work with \gls{ROS} 2.
\section{ROS-Enabled Hardware Framework}
\label{sec:ros-enabled-hardware-framework}
In 2019 Strohmer et al. \cite{rehf} present a \emph{ROS-Enabled Hardware Framework}.
Their framework relies on programmable \gls{SOC} with at least 2 \gls{CPU} cores that can be run independently of each other.
One core runs \gls{ROS} on a Linux distribution, the other core runs the control algorithm loop responsible for the \gls{PS}-\gls{PL} interface on bare-metal, and the \gls{FPGA} is responsible for handling of input and output signals and memory distributions (mirroring) via TosNet\cite{tosnet} when multiple \gls{FPGA} are used in a distributed network.
%REF:The presented framework is confirmed to be a viable control option for distributed robotics architectures which require feedback control loop speeds of up to 1.48kHz and can tolerate jitter of up to 673μs.
\section{ReconfROS}
\label{sec:reconfros}
In 2021 Eisoldt et al. \cite{reconfros} (see also \cite{reconfros2}) propose \emph{ReconfROS}, a platform using memory shared section for communicating between the \gls{PS} and \gls{PL} side\footnote{This implies a programable \gls{SOC} which shares (parts) of its memory between \gls{PS} and \gls{PL}.}.
A \gls{ROS} node running on the \gls{PS} side is using memory mapped registers from the \gls{PL} processing block to control the start/stop and inputs of the acceleration kernel. If the inputs/outputs are too large to be directly communicated via registers, a pass-by-reference approach is used where the memory address containing the actual value is passed via the registers instead, and the respective receiver has to fetch the value itself from memory.
The \gls{CMA} in the Linux Kernel is used to guarantee contiguous memory allocation, and invalidate \gls{CPU} cache to allow this communication schema.\\
As a case study an image-based trail detection algorithm is accelerated on a PYNQ-Z2\footnote{Xilinx Zynq-7000 XC7Z020-1CLG400C.} board.
%REF: The measurements of the software implementation were performed on the Intel NUC of the Ceres robot, while the FPGA-accelerated implementation was tested on the PYNQ-Z2 board. The numbers indicate that, on average, the algorithm ran almost three times faster in hardware. Furthermore, the maximum runtime of one iteration of the algorithm in software was almost two times longer compared to hardware. Further testing showed that to run as fast as in hardware, the input image resolution needs to be less than 50% in both dimensions for the software implementation.
\section{ReconROS}
\label{sec:reconros}
In 2020 Lienen et al. \cite{reconros} present \emph{ReconROS}, a framework that integrates \gls{ROS} 2 with ReconOS\cite{reconos}.
ReconOS extends the Linux \gls{OS} multi-threading by allowing threads to be run on reconfigurable slots in the \gls{PL} side (so called hardware threads).
An \gls{OSIF} and an \gls{OSFSM} running on the \gls{PL} side allow the hardware thread seamless interaction with \gls{OS} calls, while a lightweight \emph{delegate thread} running on the \gls{PS} side is actually executing the respective \gls{OS} calls.
A \gls{MEMIF} allows the hardware thread access to shared memory, and allows pass-by-reference communication.
A \emph{ReconROS Stack} was added, which extends the set of ReconOS objects with four new objects (\emph{rosnode}, \emph{rossub}, \emph{rospub}, and \emph{rosmsg}), and a \emph{ReconROS \gls{API}} which abstracts the standard \gls{ROS} 2 \gls{API} and allows access to the ReconROS Stack objects.
Initially the ReconROS \gls{API} included only three functions (\emph{ROS_SUBSCRIBER_TAKE}, \emph{ROS_SUBSCRIBER_TRY_TAKE}, and \emph{ROS_PUBLISHER_PUBLISH}).\\
A case study measuring the communication times using a ping-pong \gls{ROS} application showed that the hardware thread has slightly increased roundtrip times, which is expected since the hardware thread does one extra copy operation into its local memory.
In 2021 Lienen et al. \cite{reconros2} extended the ReconROS Stack/\gls{API} and added support for \gls{ROS} services and \gls{ROS} actions.
\gls{ROS} 2 allows event-driven programming via callbacks with the help of \emph{\gls{ROS} 2 Executors}, which are responsible for executing the registered callback functions.\\
In 2022 Lienen et al. \cite{reconros3} present the \emph{ReconROS Executor}, a \gls{ROS} 2 Executor replacement, that allows callbacks to be executed in hardware threads in the \gls{PL} side.
The ReconROS Executor also allows partial hardware reconfiguration, by allowing multiple callbacks to be registered onto the same reconfigurable slot in the \gls{PL} side, and dynamically reconfigure the slot using ZyCAP\cite{zycap}.
%REF: ReconOS provides an architecture and programming model to enable shared memory multi-threading for software and hardware threads.
%REF: The hardware threads are mapped to reconfigurable slots and are connected to the Linux operating system kernel running on the CPU via the operating system interface (OSIF) and to shared memory via the memory interface (MEMIF). A so-called operating system finite state machine (OSFSM) is attached to each hardware thread to serialize the thread’s operating system interactions.
\section{\acrshort{COMTA}}
\label{sec:comta}
In 2018 Ishida et al. \cite{comta} (see also \cite{comta2}) propose a \gls{COMTA}, which is a processing system that uses hardware accelerators.
A \emph{\gls{COMTA} Controller Object} running externally (e.g. on a connected PC) is responsible for activating and controlling a programmable \gls{SOC} with its hardware accelerators using an image file stored on a SD card connected to the programmable \gls{SOC} and a \gls{XML} based configuration file describing the data flow through the system.
An \emph{\gls{FPGA} Controller Object} running on the \gls{PS} side of the programmable \gls{SOC} is responsible for communicating with the actual acceleration kernel running on the \gls{PL} side via \gls{FIFO} buffers.
Shared memory is used in the \gls{PS} side to communicate with the \emph{\gls{FPGA} Controller Object} to reduce the communication overhead introduced by the normal use of the \gls{ROS} 1 Interfaces\footnote{Meaning shared memory is used to transfer data from the \gls{ROS} 1 nodes to the \emph{\gls{FPGA} Controller Object}.}.
The authors state that \gls{COMTA} should automatically generate all relevant nodes/objects/interfaces in the system.
%REF: We propose a “connective object for middleware to accelerator (COMTA),” which is a processing system that uses hardware accelerators, i.e., field programmable gate arrays (FPGAs), and robot middleware.
%REF: COMTA automatically constructs a processing system that including a hardware accelerator from ROS space.
%REF: We propose to automatically generate the hardware accelerated intelligent processing system and its specialized hardware accelerator via the ROS interfaces, which is possible by using a block of programs called an “object”.
%REF: The hw/sw complex system is activated using an image file on an SD card.
%REF: In a human-tracking application which is commonly used as domestic service robots, the human detection accuracy of the proposed system is equivalent to that of a general PC system. The power efficiency of the proposed system was found to be 5.2 times better than that of the general PC system. In addition, the CPU utilization on the PC of the proposed system was 50 points less than that of the conventional system.
\section{RobotCore}
\label{sec:robotcore}
In 2022 Mayoral-Vilches et al. \cite{robotcore} present \emph{RobotCore}\footnote{Note that \textbf{ROBOTCORE} is a registered trademark of a commercial solution by Acceleration Robotics, based on the same work.}, an open target- and accelerator-agnostic architecture integrating hardware acceleration in \gls{ROS} 2.
Vendor-specific tools are abstracted from the \gls{ROS} 2 build system (\emph{ament}) with the help of the \emph{ament_acceleration} meta \gls{ROS} package, which can be extended to support different tools\footnote{E.g. The \emph{ament_vitis} extension supports Xilinx Vitis, whereas the \emph{ament_jetpack} extension supports Nvidia Jetpack.}.
The \gls{ROS} 2 meta build tool (\emph{colcon}) is extended by the \emph{colcon-acceleration} package to integrate hardware acceleration flows into the \gls{CLI} (Like selecting target accelerator, generate/mount/unmount raw SD card images with Linux kernels, emulate said Linux images, etc).
A \gls{ROS} 2 meta package called \emph{acceleration_firmware} can be extended by other packages to add firmware artifact dependencies for various vendors and platforms\footnote{E.g. The \emph{acceleration_firmware_kv260} extension adds support for the Xilinx Kria KV260 board.}.
\gls{LTTNG} is used for low-overhead real-time tracing and benchmarking.\\
The proposed architecture is used to accelerate the \gls{ROS} perception pipeline (\emph{image_pipeline} \gls{ROS} package) on a Xilinx Kria KV260 board\footnote{Xilinx Zynq UltraScale+ MPSoC (XCK26).} achieving a 6.22\% (x0.0622) speedup by simply offloading 2 \gls{ROS} nodes to the \gls{FPGA}. After identifying \gls{ROS} 2 communication overheads between two \gls{ROS} nodes, an intra-\gls{FPGA} communication queue using \gls{AXIS} was used to achieve a speedup of 24.42\% (x0.2442).
A \gls{ROS} 2 community working group called \gls{HAWG} was formed, which later formalized this work as a \gls{REP} (REP-2008\cite{rep-2008}).
Xilinx also included this work in their \gls{KRS}\cite{krs} targeted at their K26 Adaptive \gls{SOM}.
\gls{KRS} additionally provides a layer for commercialization of \gls{ROS} accelerated applications through the Xilinx App Store, and provides multiple components to mitigate sources of indeterminism in various layers of the architecture to help the system be deterministic and respond in real-time.
%REF: In this work, we address this challenge with RobotCore, an architecture to integrate hardware acceleration in the widely-used ROS 2 robotics software framework. This architecture is target-agnostic (supports edge, workstation, data center, or cloud targets) and accelerator-agnostic (supports both FPGAs and GPUs). It builds on top of the common ROS 2 build system and tools and is easily portable across different research and commercial solutions through a new firmware layer.
%REF: We facilitate this emerging direction by implementing a vendor and platform-agnostic abstraction layer for hardware acceleration in robotics
%NOTE: https://ken.ieice.org/ken/paper/20220607BCKn/eng/
%This paper states a ROS 2 hardware implementation, but unfortunately I cannot get access to the paper or the code, so I'm left only with the name "ROS2rapper", and the promise (REF: https://logmi-jp.translate.goog/tech/articles/328167?_x_tr_sl=ja&_x_tr_tl=en&_x_tr_hl=en&_x_tr_pto=sc) to release the code under LGPL...
\chapter{Implementation}
\label{ch:implementation}
As already mentioned in \cref{Chapter}{ch:related-work}, no hardware based open-source implementations of the \gls{RTPS}/\gls{DDS} specifications are known.\\
Contrary to the top-down approach of others work, where integrating \gls{ROS} into hardware is in the foreground, and middleware/communication related integration is an extension of those efforts, this work takes a bottom-up approach, where integrating the \gls{RTPS}/\gls{DDS} standards into hardware are in the foreground, and extension with \gls{ROS} functionality is an extension of this effort.
\gls{RTPS} was designed to meet the needs of independent peer-to-peer systems, scale to large systems, operate in dynamic environments, support open-ended systems where applications can appear and disappear, move to new \gls{IP} addresses and remain in continuous operation for long periods of time, and also built to support protocol revisions without breaking interoperability.
Because of these requirements \gls{RTPS} includes features, such as 16-Byte \glspl{GUID} for all Endpoints in the system, 8-Byte sequence numbers, automatic discovery, propagation of type information\footnote{Strictly speaking this is part of the \gls{DDS-XTYPES} Specification \cite{dds-xtypes}.}, support for protocol and data evolution, etc.
These features make \gls{RTPS} complex and overhead heavy, which make it difficult to implement in resource constrained devices and \glspl{FPGA}.\\
This is also exactly the reason why \gls{OMG} released the \gls{DDS-XRCE} specification. And although a hardware implementation using the \gls{DDS-XRCE} protocol similar to micro-ROS would probably make more sense for this work, it was determined that a "full-fledged" protocol implementation of \gls{RTPS} and \gls{DDS} would benefit the open-source community the most, going by the general popularity \gls{RTPS}/\gls{DDS} is experiencing, beyond the use associated with \gls{ROS}.
%REF: RTPS is a binary protocol that was built for IoT applications. While it is more efficient than other IoT/IIoT protocols, such as AMQP and MQTT (Possible Ref: https://www.hindawi.com/journals/jcnc/2022/7368691/)
\section{Common Interfaces}
\label{sec:common-interfaces}
Throughout the implementation some common interfaces are used for communication between implementation entities and user.
This interfaces are described in the section.
\subsection{Start/Done Interface}
\label{subsec:start-done-interface}
The \emph{Start/Done} Interface is used for command interfaces, whenever an entity (client) wants to initiate an operation on another entity (server).
The signals required are \emph{start}, \emph{opcode}, \emph{ack}, \emph{done}, and \emph{return_code}.
Whenever the client wants to initiate an operation, he asserts the \emph{start} signal, while holding the respective operation code in the \emph{opcode} signal (and any other required operation input signals) valid until the server acknowledges the operation by asserting the \emph{ack} signal.
The server signals the end of the operation by asserting the \emph{done} signal for one clock cycle, and the return code of the operation resides in the \emph{return_code} signal in the same clock cycle.
\subsection{Ready/Valid Interface}
\label{subsec:ready-valid-interface}
The \emph{Ready/Valid} Interface is used for data transfer between entities.
The signals required are \emph{ready}, \emph{valid}, \emph{data}, and \emph{last_word}.
The writer holds the data valid in the \emph{data} signal and asserts the \emph{valid} signal, until the the reader acknowledges the transaction by asserting the \emph{ready} signal.
The reader can keep the \emph{ready} signal asserted to signify his readiness to accept transactions, but the \emph{valid} signal should not depend on the \emph{ready} signal.
The \emph{last_word} signal is asserted on the last data transaction to indicate the end of the data transfer.
\subsection{Extended \acrshort{FIFO} Interface}
\label{subsec:extended-fifo-interface}
Similar to the \emph{Ready/Valid} Interface, the known \gls{FIFO} Interface is extended by an additional Signal (\emph{last_word}) to allow to track logical ends of data payloads.
This signal is passed and stored inside the \gls{FIFO} along with the actual data signal.
The signals that defines the \gls{FIFO} are \emph{write}, \emph{data_in}, \emph{last_word_in}, \emph{full}, \emph{read}, \emph{data_out}, and \emph{last_word_out} signals.
If the \emph{full} signal is not asserted the \gls{FIFO} can accept input.
By asserting the \emph{write} signal, the contents of the \emph{data_in} and \emph{last_word_in} signals are latched into the \gls{FIFO}.
This implementation exclusively uses \gls{FWFT} \glspl{FIFO}, meaning that the next data to be consumed is already valid in the output of the \gls{FIFO}.
If the \emph{empty} signal is not asserted, the \emph{data_out} and \emph{last_word_out} signal contain valid data.
By asserting the \emph{read} signal the "displayed" data is "consumed" and the next data (if available) is shown in the \gls{FIFO} outputs.
\section{\acrshort{RTPS}}
\label{sec:impl-rtps}
\begin{figure}[htp]
\centering
\includegraphics[width=\textwidth]{graphics/system_overview-DDS.pdf}
\caption{\acrshort{RTPS}/\acrshort{DDS} Architecture Overview}
\label{fig:rtps-dds-architecture-overview}
\end{figure}
\cref{Figure}{fig:rtps-dds-architecture-overview} shows the architecture overview of the \gls{RTPS} (and \gls{DDS}) implementation.\\
Following Sections elaborate all shown components.
\subsection{\acrshort{RTPS} Handler}
\label{subsec:rtps-handler}
The \emph{\gls{RTPS} Handler} is a first-stage decoder for the \gls{RTPS} protocol.
It parses the \gls{RTPS} Header and \gls{RTPS} Submessages, interprets \hyperref[par:interpreter-submessages]{Interpreter-Submessages}, splits the \hyperref[par:entity-submessages]{Entity-Submessages} into custom format packets and forwards them to their respective destinations.
All parts of the Submessages are parsed and checked for validity, except for the payloads of DATA Submessages, which are passed as a "black box" to their destinations.
This leads to protocol noncompliance (see \cref{Section}{par:nonconformance-1}).
Since fragmented data is optional behavior, the \emph{DataFrag}, \emph{HeartbeatFrag}, and \emph{NackFrag} Submessages are not parsed, and thus not checked for validity.
This also leads to protocol noncompliance (see \cref{Section}{par:nonconformance-2}).\\
The input format of the \gls{RTPS} Handler is shown in \cref{Listing}{lst:rtps-in-out}.
The output format of the \gls{RTPS} Handler is shown in \cref{Listing}{lst:rtps-handler-out}, and the associated format of the HEARTBEAT, ACKNACK, and GAP payload format is shown in \cref{Listing}{lst:rtps-handler-out-heartbeat}, \cref{Listing}{lst:rtps-handler-out-acknack}, and \cref{Listing}{lst:rtps-handler-out-gap}, respectively\footnote{See the \gls{DDSI-RTPS} specification \cite{rtps} for explanation of the fields.}.
There is no custom DATA payload format, because the original payload contents are transferred as is (black box).
\begin{lstlisting}[basicstyle=\ttfamily\small,float,captionpos=b,caption={Input/Output Format of \acrshort{RTPS} System.},label={lst:rtps-in-out}]
31............24..............16..............8...............0
| | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+---------------------------------------------------------------+
01| SRC_IPv4_ADDR |
+---------------------------------------------------------------+
02| DEST_IPv4_ADDR |
+-------------------------------+-------------------------------+
03| SRC_UDP_PORT | DEST_UDP_PORT |
+-------------------------------+-------------------------------+
04| PACKET_LENGTH |
+---------------------------------------------------------------+
05| |
~ PACKET ~
**| |
+---------------------------------------------------------------+
\end{lstlisting}
\subsection{\acrshort{RTPS} Discovery Module}
\label{subsec:rtps-discovery-module}
The \emph{\gls{RTPS} Discovery Module} is responsible for handling meta-traffic and implements the \gls{PDP} and \gls{EDP} defined by the \gls{RTPS} specification.
Currently only \gls{SPDP} and \gls{SEDP} are supported.\\
The local participant and endpoint data is statically generated during synthesis, stored in \gls{ROM} and sent out in regular intervals\footnote{Participant data is sent on a timer, and Endpoint data is sent on-demand.}.\\
The \gls{RTPS} and \gls{DDS} specification define built-in endpoints that exchange parameter lists with pre-defined parameters containing all the relevant information for the discovery of participants and their endpoints.
And although the built-in endpoints are supposed to retain all this exchanged information based on the configured retention policy, and the matching between remote and local entities is based on compatible \gls{QOS} in the \gls{DDS} layer, the design decision was made to only retain a subset of the relevant information, and bring the matching logic inside the discovery module in the \gls{RTPS} layer\footnote{This means, that there are no \gls{DDS} built-in endpoints, and the discovery module never crosses the \gls{RTPS}-\gls{DDS} boundary and stays exclusively in the \gls{RTPS} layer}.
This again leads to protocol noncompliance (see \cref{Section}{par:nonconformance-3}).
The \gls{RTPS} Discovery Module uses memory to store information on the remote participants.
Although originally it stored also information on the contained endpoints of the remote participants, this was removed, since this information is already stored in the local endpoints and is of no real importance to the Discovery Module.\\
Whenever a compatible remote participant is discovered, it is checked if the remote participant is already in the memory, and if not is stored there (see \cref{Section}{subsubsec:dm-memory-frame-format} for the memory frame format).
If data with a newer sequence number is received with information on an already stored remote participant, the stored information is updated.
Since information on the contained endpoints of the remote participants is not stored by the \gls{RTPS} Discovery Module, every time publication or subscription data with a new sequence number is received an \emph{Endpoint Match Frame} (see \cref{Listing}{lst:endpoint-match-frame}) is sent to the compatible local endpoints, and an \emph{Endpoint Unmatch Frame} (see \cref{Listing}{lst:endpoint-unmatch-frame}) is sent to the rest.
This means that the Discovery Module is doing the compatibility check between remote and local endpoints, and is then forwarding the remote endpoint information for storing in the local endpoints, or informs the local endpoints to remove the stored information.
If a remote participant changes and becomes incompatible (or fails to assert its liveliness) it is removed from the local memory, and a \emph{Participant Unmatch Frame} (see \cref{Listing}{lst:participant-unmatch-frame}) is sent to all local endpoints, in order to remove all stored information of the remote endpoints of that remote participant.
The discovery module is also responsible for implementing the LIVELINESS \gls{QOS} AUTOMATIC and MANUAL_BY_PARTICIPANT.
Whenever a remote endpoint asserts its liveliness, an \emph{Endpoint Liveliness Update} (see \cref{Listing}{lst:endpoint-liveliness-update}) is sent to the relevant local endpoints.
The design decision was made to not support PARTITION \gls{QOS} and coherent sets of the PRESENTATION \gls{QOS}, and also not fully support general-purpose data exchange via the built-in \emph{DCPSParticipantMessage} topic, which leads to protocol noncompliance (see \cref{Section}{par:nonconformance-4}, \cref{Section}{par:nonconformance-5}, and \cref{Section}{par:nonconformance-6}).
%REF: The HEARTBEATs are sent out together with the liveliness assertions. This adds a 96-Byte overhead to the output RTPS Message. This was done to prevent having to loop through the memory to find remote participant destination more than once.
%REF: The Publisher, Subscriber, and Message Data is written on separate RTPS Messages, even though they are sent simultaneously. This decision was made to support as many local Endpoints as possible. We could make a compile-time check and sent them in the same RTPS Message/UDP Packet, but the overhead is quite small and not worth the hassle.
\subsubsection{Memory Frame Format}
\label{subsubsec:dm-memory-frame-format}
The information of the remote participants are stored in \emph{Participant Data} memory frames (see \cref{Listing}{lst:participant-data-memory-frame}).
The memory frame fields are explained below:
\begin{itemize}
\item GUIDPREFIX\\
The GUIDPREFIX of the remote participant.
\item META_IPv4_ADDRESS\\
The IPv4 Address for the built-in endpoints of the remote participant.
\item DEFAULT_IPv4_ADDRESS\\
The default IPv4 Address of the endpoints of the remote participant (if they do not specify their own)
\item META_UDP_PORT\\
The \gls{UDP} port for the built-in endpoints of the remote participant.
\item DEFAULT_UDP_PORT\\
The default \gls{UDP} port of the endpoints of the remote participant (if they do not specify their own)
\item SPDP_SEQ_NR\\
The sequence number of the last received \hyperref[subsubsec:built-in-rtps-endpoint]{DCPSParticipant} topic data.
\item LEASE_DURATION\\
The duration from the last receival of data from the remote participant, after which the remote participant is not considered alive anymore (is considered stale).
\item LEASE_DEADLINE\\
The time after which the remote participant is considered stale and subject to removal.
This field gets updated each time data is received from the remote participant.
\item P/S/M Flags\\
These Flags control what information will be sent to the remote participant.
\item ACKNACK_RES_TIME\\
The time after which the requested data will be sent to the remote participant.
\item HEARTBEAT_RES_TIME\\
The time after which an ACKNACK will be sent in response to the received HEARTBEAT Submessages.
\item PUBLICATION_SEQ_NR\\
The sequence number of the last received \hyperref[subsubsec:built-in-rtps-endpoint]{DCPSPublication} topic data.
\item SUBSCRIPTION_SEQ_NR\\
The sequence number of the last received \hyperref[subsubsec:built-in-rtps-endpoint]{DCPSSubscription} topic data.
\item MESSAGE_SEQ_NR\\
The sequence number of the last received \hyperref[subsubsec:built-in-rtps-endpoint]{DCPSParticipantMessage} topic data.
\item NEXT_ADDRESS\\
The memory address of the next participant data memory frame in the list.
\item PREV_ADDRESS\\
The memory address of the previous participant data memory frame in the list.
\end{itemize}
\begin{lstlisting}[basicstyle=\ttfamily\small,float,captionpos=b,caption={Participant Data Memory Frame Format},label={lst:participant-data-memory-frame}]
31............24..............16..............8...............0
| | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+---------------------------------------------------------------+
00| |
+ +
01| GUIDPREFIX |
+ +
02| |
+---------------------------------------------------------------+
03| META_IPv4_ADDRESS |
+---------------------------------------------------------------+
04| DEFAULT_IPv4_ADDRESS |
+-------------------------------+-------------------------------+
05| META_UDP_PORT | DEFAULT_UDP_PORT |
+-------------------------------+-------------------------------+
06| |
+ SPDP_SEQ_NR +
07| |
+---------------------------------------------------------------+
08| |
+ LEASE_DURATION +
09| |
+---------------------------------------------------------------+
10| |
+ LEASE_DEADLINE +
11| |
+---------------------------------------------------------+-+-+-+
12| UNUSED |P|S|M|
+---------------------------------------------------------+-+-+-+
13| |
+ ACKNACK_RES_TIME +
14| |
+---------------------------------------------------------------+
15| |
+ HEARTBEAT_RES_TIME +
16| |
+---------------------------------------------------------------+
17| |
+ PUBLICATION_SEQ_NR +
18| |
+---------------------------------------------------------------+
19| |
+ SUBSCRIPTION_SEQ_NR +
20| |
+---------------------------------------------------------------+
21| |
+ MESSAGE_SEQ_NR +
22| |
+---------------------------------------------------------------+
23| NEXT_ADDRESS |
+---------------------------------------------------------------+
24| PREV_ADDRESS |
+---------------------------------------------------------------+
\end{lstlisting}
\subsection{\acrshort{RTPS} Reader}
\label{subsec:rtps-reader}
The \emph{\gls{RTPS} Reader} is primarily responsible for adding new \gls{RTPS} CacheChanges received from remote writer endpoints to the local \gls{RTPS} HistoryCache.
Originally this entity represented only a single \gls{RTPS} reader endpoint, but at a later stage it was realized that the resource utilization was too inefficient.
Since the main \gls{FSM} needs the most resources and is the same for all \gls{RTPS} readers, it was decided to redesign the entity to represent all \gls{RTPS} reader endpoints using the same \gls{FSM}.
Although this change basically made the resource utilization scale logarithmically (instead of linearly) with the number of endpoints, the individual endpoints have to act sequentially and cannot act in parallel, as would be possible with the previous implementation.
This design decision was subsequently applied also to \gls{RTPS} writer, \gls{DDS} reader, and \gls{DDS} writer endpoints, significantly reducing the resource usage\footnote{3 \gls{RTPS}/\gls{DDS} reader endpoints and 6 \gls{RTPS}/\gls{DDS} writer endpoints need comparatively 42\% less resources.}.
All inputs (meta-traffic or user-traffic) are parsed once\footnote{DATA Submessage payloads are stored in a dedicated temporal memory.} for all readers, but then handled for each relevant reader individually.
If an input is relevant for a particular reader is reflected in the empty signal of the input \gls{FIFO} (see \cref{Section}{subsec:vector-fifo}).
In contrast output is only written by one reader at a time, and never in parallel.
The entity iterates through the readers in round robin fashion.\\
Each reader has its own memory containing the matched remote writer endpoints (see \cref{Section}{subsubsec:rtps-reader-memory-frame-format} for the memory frame format), based on the meta-traffic received from the \gls{RTPS} Discovery Module.
For a reference on the possible meta-traffic input formats see \cref{Section}{subsec:rtps-discovery-module}.\\
Only traffic from remote endpoints already residing in the local memory (i.e. already matched) is accepted.
This entity can receive HEARTBEAT, GAP, or DATA Submessages as user-traffic from remote writer endpoints.
The next expected sequence number of each remote matched writer is stored in memory, and can be modified by the receival of an HEARTBEAT Submessage (if the remote writer no longer has the expected sequence number), or a GAP Submessage (if the next expected sequence number is in the GAP list).
For a reference on the possible user-traffic input formats see \cref{Section}{subsec:rtps-handler}.
Only the Key Hash (see \cref{Section}{par:key-hash}) and Instance State Change (see \cref{Section}{par:instance-state-transition}) are parsed from the inline \gls{QOS} of a DATA Submessage.
The \gls{RTPS} Reader interacts with the \gls{RTPS} HistoryCache via the \hyperref[subsec:start-done-interface]{start/done interface}.
The only 2 possible operations are \emph{ADD_CACHE_CHANGE} and \emph{REMOVE_WRITER} (see \cref{Timing Diagram}{tim:add-cache-change} and \cref{Timing Diagram}{tim:remove-writer}).
Only DATA Submessages with the next expected sequence number (from that remote endpoint writer) are accepted, and propagated to the \gls{RTPS} HistoryCache with the \emph{ADD_CACHE_CHANGE} operation.
Whenever a previously matched remote writer endpoint is removed via meta-traffic or gets stale\footnote{Fails to assert his Liveliness in the configured interval.}, the remote endpoint is removed from the local memory and the REMOVE_WRITER operation is initiated on the \gls{RTPS} HistoryCache\footnote{Note that this is subjective to each local endpoint, meaning that the remote writer endpoint may get stale and be subject to removal only for one of the local reader endpoints.}.\\
Following the acknowledgment of the \emph{ADD_CACHE_CHANGE} operation, a data transfer (see \cref{Listing}{lst:add-cache-change-format}) takes place using the \hyperref[subsec:ready-valid-interface]{ready/valid interface}.\\
The \emph{REMOVE_WRITER} operation is similar, with the exception that there is no data transfer taking place using the \hyperref[subsec:ready-valid-interface]{ready/valid interface}, but instead the only data word to be transferred (see \cref{Listing}{lst:remove-writer-format}) is put on the data signal at the same time the \emph{start} signal is asserted (latched together with the start of the operation).
\subsubsection{Memory Frame Format}
\label{subsubsec:rtps-reader-memory-frame-format}
The information of the remote writer endpoints are stored in \emph{Writer Endpoint Data} memory frames (see \cref{Listing}{lst:writer-endpoint-data-memory}).
The memory frame fields are explained below:
\begin{itemize}
\item ENTITYID\\
The ENTITYID of the remote writer endpoint.
\item GUIDPREFIX\\
The GUIDPREFIX of the remote writer endpoint.
\item IPv4_ADDRESS\\
The \gls{IP} version 4 Address of the remote writer endpoint.
This field exists only if the local reader endpoint is configured for reliable communication.
\item UDP_PORT\\
The \gls{UDP} port of the remote writer endpoint.
This field exists only if the local reader endpoint is configured for reliable communication.
\item NEXT_SEQ_NR\\
The Sequence Number of the next expected DATA Submessage from the remote writer endpoint.
Received DATA Submessages with different Sequence Number are ignored.
\item LEASE_DEADLINE\\
The time after which the remote writer endpoint is considered stale and subject to removal.
This field gets updated each time the remote writer endpoint asserts his liveliness.
\item LIFESPAN_DURATION\\
The duration for which data (from the payload of received DATA Submessages) is considered valid, after which it should be removed.
\item RES_TIME\\
The time after which an ACKNACK will be sent to the remote writer endpoint.
This field exists only if the local reader endpoint is configured for reliable communication.
\item WRITER_ID\\
A unique read-only \gls{ID} (incrementing integer) given to each memory frame.
This \gls{ID} is used to identify remote writer endpoints and can be used for bitmap indexing (see \emph{WRITER_BITMAP} in \cref{Section}{subsubsec:dds-reader-memory-frame-format}).
\end{itemize}
\begin{lstlisting}[basicstyle=\ttfamily\small,float,captionpos=b,caption={Writer Endpoint Data Memory Frame Format},label={lst:writer-endpoint-data-memory}]
31............24..............16..............8...............0
| | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+---------------------------------------------------------------+
00| ENTITYID |
+---------------------------------------------------------------+
01| |
+ +
02| GUIDPREFIX |
+ +
03| |
+---------------------------------------------------------------+
04| IPv4_ADDRESS [Reliable Only] |
+-------------------------------+-------------------------------+
05| UDP_PORT [Reliable Only] | UNUSED [Reliable Only] |
+-------------------------------+-------------------------------+
06| |
+ NEXT_SEQ_NR +
07| |
+---------------------------------------------------------------+
08| |
+ LEASE_DEADLINE +
09| |
+---------------------------------------------------------------+
10| |
+ LIFESPAN_DURATION +
11| |
+---------------------------------------------------------------+
12| |
+ RES_TIME [Reliable Only] +
13| |
+---------------------------------------------------------------+
14| WRITER_ID |
+---------------------------------------------------------------+
15| NEXT_ADDR |
+---------------------------------------------------------------+
16| PREV_ADDR |
+---------------------------------------------------------------+
\end{lstlisting}
\subsection{\acrshort{RTPS} Writer}
\label{subsec:rtps-writer}
The \emph{\gls{RTPS} Writer} is primarily responsible for reading and deleting \gls{RTPS} CacheChanges received from remote reader endpoints from the local \gls{RTPS} HistoryCache.\\
Similar to the \hyperref[subsec:rtps-reader]{\gls{RTPS} Reader} this entity represents all \gls{RTPS} writer endpoints.
All inputs (meta-traffic or user-traffic) are parsed once for all writers, but then handled for each relevant writer individually.
If an input is relevant for a particular writer is reflected in the empty signal of the input \gls{FIFO} (see \cref{Section}{subsec:vector-fifo}).
In contrast output is only written by one writer at a time, and never in parallel.
The entity iterates through the writers in round robin fashion.\\
Each writer has its own memory containing the matched remote reader endpoints (see \cref{Section}{subsubsec:rtps-writer-memory-frame-format} for the memory frame format), based on the meta-traffic received from the \gls{RTPS} Discovery Module.
For a reference on the possible meta-traffic input formats see \cref{Section}{subsec:rtps-discovery-module}.\\
This entity can only receive ACKNACK Submessages as user-traffic from (reliable) remote matched reader endpoints, with which they can acknowledge\footnote{Confirm as received.} and/or request missing sequence numbers.
This entity has an internal sequence number that is incremented on each new \gls{RTPS} CacheChange.
Depending on the setting of \emph{PUSH_MODE} a new \gls{RTPS} CacheChange is sent immediately, or only after the remote reliable reader has requested it via an ACKNACK Submessage.
A request bitmap (of a range of up to 32 sequence numbers), and the sequence number of the last acknowledged SN of each remote endpoint are stored in the local memory\footnote{Note that only reliable readers can send ACKNACKs.}.
A global signal contains the highest common acknowledged sequence numbers of all remote reader endpoints (remote best effort readers are ignored), and allows the \gls{RTPS} Writer to mark the sequence number as acknowledged in the \gls{RTPS} HistoryCache.
Even though the LIVELINESS \gls{QOS} (and by extension the \gls{RTPS} Liveliness Protocol) is only defined for the writers, this implementation defines a liveliness also for reliable\footnote{Since best effort readers do not send out any traffic, we cannot know their liveliness status.} readers.
The liveliness is renewed whenever traffic is received from the remote reader.
The \gls{RTPS} Writer interacts with the \gls{RTPS} HistoryCache via the \hyperref[subsec:start-done-interface]{start/done inetrface}.
The allowed operations are \emph{GET_CACHE_CHANGE}, \emph{ACK_CACHE_CHANGE}, \emph{NACK_CACHE_CHANGE}, \emph{REMOVE_CACHE_CHANGE}, \emph{GET_MIN_SN}, and \emph{GET_MAX_SN} (see \cref{Timing Diagram}{tim:get-cache-change}, \cref{Timing Diagram}{tim:nack-cache-change}, and \cref{Timing Diagram}{tim:get-min-sn}).
Everytime new data is available in the \gls{RTPS} HistoryCache, or data needs to be fetched to satisfy a reader request the GET_CACHE_CHANGE operation is executed.
Once a sequence number has been acknowledged by all matched remote (reliable) readers, either the \emph{ACK_CACHE_CHANGE} operation is performed on the \gls{RTPS} HistoryCache to convey this information\footnote{An acknowledged \gls{RTPS} CacheChange is subject to removal, depending on the configured \gls{QOS}.}, or the REMOVE_CACHE_CHANGE operation is executed to remove the \gls{RTPS} CacheChange from the \gls{RTPS} HistoryCache\footnote{If the local endpoint is configured with DURABILITY \gls{QOS} VOLATILE.}.
Requested sequence numbers from remote endpoint readers, on the other hand, are negative acknowledged using the NACK_CACHE_CHANGE operation.
In order to formulate a HEARTBEAT Submessage the \gls{RTPS} Writer has to know the highest and lowest sequence number still available in the \gls{RTPS} HistoryCache\footnote{Since the \gls{RTPS} HistoryCache can delete \gls{RTPS} CacheChanges without the knowledge of the \gls{RTPS} Writer.}, which it gets with the GET_MIN_SN and GET_MAX_SN operations.\\
All operations except GET_MIN_SN and GET_MAX_SN need to also set the \emph{seq_nr} signal along with the \emph{start} signal, which denotes the sequence number for which the operation is relevant.
After the operation is done, the \gls{RTPS} HistoryCache asserts the \emph{done} signal and sets the \emph{ret} signal to the return status of the operation for one clock cycle.
On a GET_CACHE_CHANGE operation if the \gls{RTPS} CacheChange also has data, it can be requested by asserting the \emph{get_data} signal on the same clock cycle the operation is done.
The requested data is transferred using the \hyperref[subsec:ready-valid-interface]{ready/valid interface}.
The transferred data is the payload of the DATA \gls{RTPS} Submessage.
From the point the operation is done (\emph{done} signal asserted) until the acknowledgment of the next operation (\emph{ack} signal asserted), the \emph{cc_*} signals are valid and contain information of the \gls{RTPS} CacheChange for the GET_* operations.
\subsubsection{Memory Frame Format}
\label{subsubsec:rtps-writer-memory-frame-format}
\begin{lstlisting}[basicstyle=\ttfamily\small,float,captionpos=b,caption={Reader Endpoint Data Memory Frame Format},label={lst:reader-endpoint-data-memory}]
31............24..............16..............8...............0
| | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+---------------------------------------------------------------+
00| ENTITYID |
+---------------------------------------------------------------+
01| |
+ +
02| GUIDPREFIX |
+ +
03| |
+---------------------------------------------------------------+
04| IPv4_ADDRESS |
+-------------------------------+-------------------------------+
05| UDP_PORT | READER_FLAGS |
+-------------------------------+-------------------------------+
06| |
+ LEASE_DEADLINE [Reliable Only] +
07| |
+---------------------------------------------------------------+
08| |
+ RES_TIME [Reliable Only] +
09| |
+---------------------------------------------------------------+
10| |
+ ACK_SEQ_NR_BASE [Reliable Only] +
11| |
+---------------------------------------------------------------+
12| |
+ REQ_SEQ_NR_BASE [Reliable Only] +
13| |
+---------------------------------------------------------------+
14| REQ_BITMAP [Reliable Only] |
+---------------------------------------------------------------+
15| NEXT_ADDR |
+---------------------------------------------------------------+
16| PREV_ADDR |
+---------------------------------------------------------------+
READER_FLAGS
------------
15............8...............0
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-------------------------+-+-+-+
| UNUSED |B|H|Q|
+-------------------------+-+-+-+
Q...Reader expects in-line QoS
H...Reader expects Historical Data
B...Reader has RELIABILITY BEST_EFFORT
\end{lstlisting}
The information of the remote reader endpoints is stored in \emph{Reader Endpoint Data} memory frames (see \cref{Listing}{lst:reader-endpoint-data-memory}).
The memory frame fields are explained below:
\begin{itemize}
\item ENTITYID\\
The ENTITYID of the remote reader endpoint.
\item GUIDPREFIX\\
The GUIDPREFIX of the remote reader endpoint.
\item IPv4_ADDRESS\\
The \gls{IP} version 4 Address of the remote reader endpoint.
\item UDP_PORT\\
The \gls{UDP} port of the remote reader endpoint.
\item READER_FLAGS\\
Flags that specify if the remote reader endpoint is expecting in-line \gls{QOS}, sending of all still available \gls{RTPS} CacheChanges sent prior to its discovery, and the reliability level of the remote reader endpoint.
\item LEASE_DEADLINE\\
The time after which the remote reader endpoint is considered stale and subject to removal.
This field gets updated each time traffic is received from the remote reader endpoint.
The special \emph{TIME_INVALID} value is stored for best effort remote reader endpoints, since they do not send user-traffic.
This field exists only if the local writer endpoint is configured for reliable communication.
\item RES_TIME\\
The time after which an HEARTBEAT will be sent in response to the received ACKNACK Submessages.
This field exists only if the local writer endpoint is configured for reliable communication.
\item ACK_SEQ_NR_BASE\\
The highest acknowledged sequence number of the remote reader endpoint\footnote{Due to the nature of the ACKNACK Submessage, only sequence numbers up to a point can be acknowledged (i.e. no out-of-order individual sequence numbers can be acknowledged).}.
This field exists only if the local writer endpoint is configured for reliable communication.
\item REQ_SEQ_NR_BASE\\
The lowest requested sequence number of the remote reader endpoint.
This field exists only if the local writer endpoint is configured for reliable communication.
\item REQ_BITMAP\\
A bitmap denoting which sequence numbers (with bit 0 representing REQ_SEQ_NR_BASE) are requested.
Since the bitmap is 32-bit wide, up to 32 sequence numbers can be requested.
This field exists only if the local writer endpoint is configured for reliable communication.
\end{itemize}
\subsection{Vector \gls{FIFO}}
\label{subsec:vector-fifo}
The \emph{Vector \gls{FIFO}} is a special kind of \gls{FIFO} that is used as input to the \gls{RTPS} endpoint entities.
Although both the \gls{RTPS} Handler and the \gls{RTPS} Discovery Module are implemented for signaling multiple \glspl{FIFO}, they write the same output to multiple \glspl{FIFO} in parallel.
Since the \gls{RTPS} endpoints also signal and consume the \glspl{FIFO} in parallel, we can use this knowledge to implement a special kind of \gls{FIFO}, which stores the value only once and stores the target destination information (i.e. the value of the \emph{write} signal vector) and later outputs this information in the \emph{empty} signal vector of the consumers\footnote{If the \emph{write} signal for a specific index was not asserted, the respective \emph{empty} signal will be asserted when the value arrives the read output.}.
\subsection{\acrshort{RTPS} Out}
\label{subsec:rtps-out}
The \emph{\gls{RTPS} Out} is the common output of the \gls{RTPS} system and responsible for crafting the final packet that is provided to the egress network stack.
The \gls{RTPS} Out latches a single packet from one of the input \glspl{FIFO} in round robin fashion, calculates and inserts the packet length, and writes it to the output \gls{FIFO}.
Because the packet length has to be calculated and stored (almost) at the beginning of the packet, the whole packet has to be stored in a buffer\footnote{The buffer has to be big enough to hold the largest possible generated packet. If the packet does not fit in the buffer, the packet is silently dropped.}, before it can be moved to the output \gls{FIFO}.
While a finished packet is transferred to the output \gls{FIFO}, the next packet can be stored into the buffer in parallel.
The input format of the \gls{RTPS} Out can be seen in \cref{Listing}{lst:rtps-out-in}.
The output format of the \gls{RTPS} Out is the same as the input format of the \gls{RTPS} Handler (see \cref{Listing}{lst:rtps-in-out}), meaning that the \gls{RTPS} Out can be directly connected to an \gls{RTPS} Handler of a different system, avoiding the network stack in between\footnote{This "feature" is used in the testbenches.}.
\section{\acrshort{DDS}}
\label{sec:impl-dds}
\cref{Figure}{fig:rtps-dds-architecture-overview} shows the architecture overview of the \gls{DDS} (and \gls{RTPS}) implementation.\\
Following Sections elaborate all shown components.
As stated in \cref{Section}{subsubsec:rtps-historycache}, the \emph{\gls{RTPS} HistoryCache} stores \emph{\gls{RTPS} CacheChanges} and is the part of the interface between \gls{DDS} and \gls{RTPS} Entities.
A \gls{DDS} Entity needs most of the information stored inside the \emph{\gls{RTPS} HistoryCache} to enforce the configured \gls{DDS} \gls{QOS}.
It also needs to return \gls{DDS} samples in a specific order based on the configured \gls{QOS}, meaning that it needs to modify the stored \emph{\gls{RTPS} CacheChange} order.
Considering the above the decision was made to integrate the \emph{\gls{RTPS} HistoryCache} directly into the \gls{DDS} Endpoint\footnote{Which is also what many existing implementations do, where there is no differentiation between \gls{RTPS} and \gls{DDS} endpoints.} to increase performance, avoid unnecessary traffic, and decrease resource utilization.
Although it was originally planned to be implemented with a dual-port memory, allowing the "\gls{RTPS} side" to store \gls{RTPS} CacheChanges while the "\gls{DDS} side" processes \gls{DDS} operations, this was later rejected since the \gls{DDS} operations demand a consistent state and would not allow to store new \gls{RTPS} CacheChanges during \gls{DDS} operations.
The \gls{DDS} Specification describes a software \gls{API}, that does not always translate well in hardware and some liberties have to be taken.
For this reason a hardware implementation of the specification will never be fully compliant.
For instance the software \gls{API} defines \emph{Listeners} for asynchronous access, and \emph{Conditions} and \emph{WaitSets} for synchronous access to the \gls{DDS} entities.
This hardware implementation on the other hand simply presents and updates a status signal (also defined in the \gls{DDS} specification), and it is up to the user implementation to either poll this status synchronously, or trigger asynchronously upon signal change.
While \gls{RTPS} Endpoints (and the \gls{RTPS} HistoryCache) manage \emph{\gls{RTPS} CacheChanges}, \gls{DDS} Endpoints manage \emph{data-samples}.
Although most \gls{RTPS} CacheChanges directly translate to a sample, this is not a direct mapping.
For example an unregister \gls{RTPS} CacheChange (which signifies that a writer has unregistered the instance) may not have a direct effect (instance state change to NOT_ALIVE_NO_WRITERS) if there are still other endpoints writing the instance, and thus do not have an associated sample.
Similarly a sample may be generated without an associated \gls{RTPS} CacheChange, for example when the last writing endpoint of an instance failed to assert its liveliness, and the instance state transitions to NOT_ALIVE_NO_WRITERS.
\gls{DDS} Publishers/Subscribers provide the functionality to create or delete DataWriters/DataReaders, which does not translate to hardware, since the DataWriters/DataReaders need to be statically predefined for the system.
\gls{DDS} Publishers/Subscribers also provide the means to access \hyperref[par:presentation]{coherent sets} with group access level, which are not supported by the implementation (see \cref{Section}{par:nonconformance-6}).
Thus \gls{DDS} Publishers and Subscribers are in our case "obsolete" and their implementation is skipped entirely.
\gls{DDS} Entities use instance handles to reference data-instances. Those are not defined in the specification and are left up to the implementation, but have the requirement of being unique and orderable.
For this implementation the decision was made to directly use the protocol defined Key Hash as instance handles.
As already mentioned, \gls{DDS} uses \gls{IDL} to specify topic types and define message (de-) serialization.\\
According to the \gls{DDS} Specification the abstract \emph{TypeSupport} class has to be automatically specialized by the implementation with types defined in \gls{IDL}.
This specialized TypeSupport classes are than registered to DomainParticipants (using the \emph{register_type} method of the TypeSupport class), which allows the DomainParticipant to create Topics based on the registered types.
The created topics can than be used to create typed-access DataReaders and DataWriters.\\
This procedure cannot be implemented as is in hardware.
The design decision was made to encapsulate all type-specific marshaling into 3 separate entities: KEY_HOLDER, <TYPENAME>_READER_INTERFACE, <TYPENAME>_WRITER_INTERFACE and "link" them as necessary.
The KEY_HOLDER has a different architecture per type, whereas the <TYPENAME>_READER_INTERFACE and <TYPENAME>_WRITER_INTERFACE get also different entity definitions per type.
\subsection{\acrshort{DDS} Reader}
\label{subsec:dds-reader}
The \emph{\gls{DDS} Reader} is primarily responsible for providing the user access to the received data.
As explained above it is also responsible for implementing the \gls{RTPS} HistoryCache, meaning it directly handles \gls{RTPS} Reader operations.
\gls{RTPS} operations are handled with a higher priority over \gls{DDS} operations.
Similar to the \hyperref[subsec:rtps-reader]{\gls{RTPS} Reader} this entity represents all \gls{DDS} Reader endpoints.
This entity contains 3 types of memories: an \emph{instance memory}, a \emph{sample memory}, and a \emph{payload memory} (see \cref{Section}{subsubsec:dds-reader-memory-frame-format} for the memory frames format).
The \emph{instance memory} contains data-instances of received samples, the \emph{sample memory} contains the sample "meta" data, and the \emph{payload memory} contains the associated data of the samples (if available).
Each \gls{DDS} Reader has its own set of memories.
The allowed \gls{RTPS} operations are ADD_CACHE_CHANGE, and REMOVE_WRITER (See \cref{Section}{subsec:rtps-reader}).
The ADD_CACHE_CHANGE operation stores the received \gls{RTPS} CacheChanges as \gls{DDS} data-samples in the local memories.
If the data of the ADD_CACHE_CHANGE does not include a Key Hash it has to be calculated manually.
For this reason a \emph{KEY HOLDER} is instantiated for each \gls{DDS} Reader, which is fed the payload/serialized key and calculates the Key Hash.
Because this has to be done before the ACCEPT/REJECT decision for the sample can be made, the sample and its possible associated payload has to be temporarily buffered.
This is solved by extending both the sample memory and payload memory by one slot, that is not counted towards the RESOURCE_LIMITS \gls{QOS}.\\
If the Key Hash of the ADD_CACHE_CHANGE is of an (yet) unknown instance, a new instance is added in the instance memory.
The instance is added in numerical Key Hash order to the instance memory, in order to support some specific \gls{DDS} operations (READ_NEXT_INSTANCE and TAKE_NEXT_INSTANCE).
If the instance memory is full (MAX_INSTANCES RESOURCE_LIMITS \gls{QOS}), the first stale\footnote{An instance is stale if the sample memory has no samples associated with the instance, and no writer is currently associated with the instance (REMOVE_WRITER was called for all writers known to write this instance).\label{footref:stale-instance}} instance is removed to make space for the new instance.
If no stale instance is available, the ADD_CACHE_CHANGE operation is rejected.\\
\gls{RTPS} CacheChanges are inserted into the Sample memory in receive order (ADD_CACHE_CHANGE order), except if the DESTINATION_ORDER QoS is set to BY_SOURCE_TIMESTAMP, in which case they are inserted based on their timestamp.
Note that in the case of BY_SOURCE_TIMESTAMP DESTINATION_ORDER QoS, no \gls{RTPS} CacheChange with a timestamp earlier than the last read sample is accepted.\\
Even though the meta-information stored in the sample memory is always the same size, the same can not be said for the payload, which can have (depending on the associated \gls{IDL} type) a more dynamic size.
Despite that, the payload memory also works with fixed-size slots.
If a payload is bigger it just occupies multiple linked memory slots.
If the end of the payload is not aligned with the end of the memory slot (which is always known due to the fixed-size nature), the end address of the payload is stored in the end of the memory slot.\\
This dynamic nature of the payload arises the situation, that during an ADD_CACHE_CHANGE operation a sample memory slot is available, but all payload memory slots are occupied.
In this situation - depending on the configured \gls{QOS} (see \cref{Table}{tab:dds-reader-max-samples}) - either the operation is directly rejected, or the oldest sample is removed from the memories.
Note that since the oldest sample may have no associated payload, multiple sample removals may be triggered\footnote{This happens also when the sample to be added has no associated payload, since this cannot be known in advance.}.
On the other hand, because this action is preliminary and before the actual decision based on the sample to be added and the configured \gls{QOS}, a situation may arise were a single ADD_CACHE_CHANGE operation may trigger multiple sample removals.
The behavior on hitting the MAX_SAMPLES and MAX_SAMPLES_PER_INSTANCE RESOURCE_LIMITS \gls{QOS} can be seen in \cref{Table}{tab:dds-reader-max-samples} and \cref{Table}{tab:dds-reader-max-samples-per-instance}, respectively.\\
\gls{RTPS} CacheChanges without associated payload are only stored as samples, if the \gls{RTPS} CacheChange causes an instance state change.
If the DESTINATION_ORDER \gls{QOS} is set to BY_SOURCE_TIMESTAMP\footnote{Which allows later received samples to be ordered before prior received ones.}, an \gls{RTPS} CacheChange that can change instance state (Unregister or Dispose) is only accepted if no newer instance samples exist, in order to keep the history consistent.\\
An instance state change to the NOT_ALIVE_NO_WRITERS instance state can also occur without receiving a \gls{RTPS} CacheChange\footnote{When the REMOVE_WRITER operation removes the last active writer of an instance.}, in which case a sample is "manually" generated.\\
The REMOVE_WRITER operation removes the specified writer from all currently stored instances, and is used to track stale\footref{footref:stale-instance} instances.
%TODO: Move the signal relation description here, since the DDS Reader is the actuator of the operation, or leave it in the RTPS Description to spread the information a bit?
The allowed \gls{DDS} operations are READ, TAKE, READ_NEXT_SAMPLE, TAKE_NEXT_SAMPLE, READ_INSTANCE, TAKE_INSTANCE, READ_NEXT_INSTANCE, TAKE_NEXT_INSTANCE, GET_SAMPLE_REJECTED_STATUS, and GET_REQUESTED_DEADLINE_MISSED_STATUS (see \cref{Timing Diagram}{tim:read}, \cref{Timing Diagram}{tim:read-next-sample}, \cref{Timing Diagram}{tim:read-instance}, and \cref{Timing Diagram}{tim:get-sample-rejected-status}).
These are a subset of the operations defined by the \gls{DDS} specification for a DataReader.
The description of the operations, their inputs, and outputs can be taken directly from the \gls{DDS} specification.
For operations returning collections of \emph{SampleInfos} and their associated data, the \emph{SampleInfos} are returned in collection order directly in the \emph{sample_info.*} signals, whereas the associated data has to be explicitly requested and is returned using a "normal" data transfer.\\
The operations follow the \hyperref[subsec:start-done-interface]{start/done interface}.
The READ and TAKE operation also need valid \emph{sample_state}, \emph{view_state}, \emph{instance_state}, and \emph{max_samples} signals while the \emph{start} signal is asserted, whereas the READ_INSTANCE, TAKE_INSTANCE, READ_NEXT_INSTANCE, and TAKE_NEXT_INSTANCE operations need in addition to those signals also a valid \emph{instance_handle} signal.
After completion (\emph{done} signal asserted), the GET_* operations initiate a data transfer using the \hyperref[subsec:ready-valid-interface]{read/valid interface} for the requested data (see \cref{Listing}{lst:get-sample-rejected-status-format} and \cref{Listing}{lst:get-requested-deadline-missed-status-format}).
All READ_* and TAKE_* operations will return at least one sample info after the operation is completed (\emph{done} signal asserted) and the return code is "RETCODE_OK".
All the \emph{sample_info.*} signals are valid when the \emph{sample_info_valid} signal is asserted.
The \emph{sample_info.*} signals stay valid until the \emph{sample_info_ack} signal is asserted.
If the sample has associated data (\emph{sample_info.valid_data} signal is asserted), the data can be requested by asserting the \emph{get_data} signal on the same clock cycle the \emph{sample_info_ack} signal is asserted.
In this case a data transfer using the \hyperref[subsec:ready-valid-interface]{read/valid interface} is initiated.
If no more samples are to be returned, the \emph{eoc} (End Of Collection) signal is asserted for one clock cycle, signifying the end of the operation.
\begin{table}
\centering
\caption{\acrshort{DDS} Reader Behavior on MAX_SAMPLES RESOURCE_LIMIT \gls{QOS}.}
\label{tab:dds-reader-max-samples}
\begin{tabular}{|l|l|l|}
\hline
\textbf{RELIABILITY QoS} & \textbf{HISTORY QoS} & \textbf{ACTION}\\
\hline
BEST_EFFORT & KEEP_ALL & Remove Oldest Sample\\
\hline
RELIABLE & KEEP_ALL & Reject Sample\\
\hline
BEST_EFFORT & KEEP_LAST & Remove Oldest Sample\\
\hline
RELIABLE & KEEP_LAST & Remove Oldest Sample\\
\hline
\end{tabular}
\end{table}
\begin{table}
\centering
\caption{\acrshort{DDS} Reader Behavior on MAX_SAMPLES_PER_INSTANCE RESOURCE_LIMIT \gls{QOS}.}
\label{tab:dds-reader-max-samples-per-instance}
\begin{tabular}{|l|l|l|}
\hline
\textbf{RELIABILITY QoS} & \textbf{HISTORY QoS} & \textbf{ACTION}\\
\hline
BEST_EFFORT & KEEP_ALL & Remove Oldest Instance Sample\\
\hline
RELIABLE & KEEP_ALL & Reject Sample\\
\hline
BEST_EFFORT & KEEP_LAST & Remove Oldest Instance Sample\\
\hline
RELIABLE & KEEP_LAST & Remove Oldest Instance Sample\\
\hline
\end{tabular}
\end{table}
\subsubsection{Memory Frame Format}
\label{subsubsec:dds-reader-memory-frame-format}
\begin{lstlisting}[basicstyle=\ttfamily\small,float,captionpos=b,caption={\acrshort{DDS} Reader Sample Data Memory Frame Format},label={lst:dds-reader-sample-data-memory}]
31............24..............16..............8...............0
| | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+---------------------------------------------------------------+
01| STATUS_INFO |
+---------------------------------------------------------------+
02| |
+ TIMESTAMP +
03| |
+---------------------------------------------------------------+
04| |
+ LIFESPAN_DEADLINE +
05| |
+---------------------------------------------------------------+
06| PAYLOAD_ADDRESS |
+---------------------------------------------------------------+
07| INSTANCE_ADDRESS [only if WITH_KEY] |
+---------------------------------------------------------------+
08| DISPOSED_GENERATION_COUNT |
+---------------------------------------------------------------+
09| NO_WRITERS_GENERATION_COUNT |
+---------------------------------------------------------------+
10| PREV_ADDRESS |
+---------------------------------------------------------------+
11| NEXT_ADDRESS |
+---------------------------------------------------------------+
STATUS INFO
-----------
31............24..............16..............8...............0
| | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+---------------------------------------------------+-+-+-+
|R|P|A| UNUSED |F|U|D|
+-+-+-+---------------------------------------------------+-+-+-+
R...Sample has been Read
P...Sample has associated DATA Payload
A...Associated Payload is aligned (Payload does extend until end of last Payload Slot)
F...FilteredFlag (1:1 PID_STATUS_INFO Mapping)
U...UnregisteredFlag (1:1 PID_STATUS_INFO Mapping)
D...DisposedFlag (1:1 PID_STATUS_INFO Mapping)
\end{lstlisting}
The meta-information of \gls{DDS} samples is stored in \emph{Sample Data} memory frames (see \cref{Listing}{lst:dds-reader-sample-data-memory}).
The memory frame fields are explained below:
\begin{itemize}
\item STATUS_INFO\\
Flags that specify if the data-sample has been read, if the data-sample has an associated payload, if the associated payload is aligned to the end of the memory slots, and the kind of the data-sample (Filter, Unregister, Dispose).
\item TIMESTAMP\\
The relevant sending/receival timestamp of the data-sample (Depends on the configured DESTINATION_ORDER \gls{QOS}).
\item LIFESPAN_DEADLINE\\
The time after which the sample is considered obsolete and will be removed.
The special value TIME_INFINITE disables the data-sample removal.
\item PAYLOAD_ADDRESS\\
The memory address of the associated payload.
\item INSTANCE_ADDRESS\\
The memory address of the associated data-instance.
This field exists only if the local reader endpoint is configured for keyed topics (WITH_KEY attribute true).
\item DISPOSED_GENERATION_COUNT\\
As defined in the \gls{DDS} specification.
\item NO_WRITERS_GENERATION_COUNT\\
As defined in the \gls{DDS} specification.
\end{itemize}
\begin{lstlisting}[basicstyle=\ttfamily\small,float,captionpos=b,caption={\acrshort{DDS} Reader Instance Data Memory Frame Format},label={lst:dds-reader-instance-data-memory}]
31............24..............16..............8...............0
| | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+---------------------------------------------------------------+
01| NEXT_ADDRESS |
+---------------------------------------------------------------+
02| PREV_ADDRESS |
+---------------------------------------------------------------+
03| |
+ +
04| |
+ KEY_HASH +
05| |
+ +
06| |
+---------------------------------------------------------------+
07| STATUS_INFO |
+---------------------------------------------------------------+
08| SAMPLE_COUNT |
+---------------------------------------------------------------+
09| DISPOSED_GENERATION_COUNT |
+---------------------------------------------------------------+
10| NO_WRITERS_GENERATION_COUNT |
+---------------------------------------------------------------+
11| |
+ IGNORE_DEADLINE +
12| [only if TIME_BASED_FILTER /= 0] |
+---------------------------------------------------------------+
13| |
~ WRITER_BITMAP ~
**| |
+---------------------------------------------------------------+
STATUS INFO
-----------
31............24..............16..............8...............0
| | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+---------------------------------------------------+-+-+-+-+-+-+
| UNUSED |G|M|V|L|W|D|
+---------------------------------------------------+-+-+-+-+-+-+
D...NOT_ALIVE_DISPOSED
W...NOT_ALIVE_NO_WRITERS
L...LIVELINESS FLAG
V...VIEW STATE
M...MARK
G...GENERATE SAMPLE
\end{lstlisting}
The instance information of samples is stored in \emph{Instance Data} memory frames (see \cref{Listing}{lst:dds-reader-instance-data-memory}).
The memory frame fields are explained below:
\begin{itemize}
\item KEY_HASH\\
The Key Hash of the instance.
\item STATUS_INFO\\
Flags defining the instance state (ALIVE, NOT_ALIVE_DISPOSED, NOT_ALIVE_NO_WRITERS), if the instance contains new samples since last access (\gls{DDS} VIEW_STATE), a liveliness flag used for the DEADLINE \gls{QOS}, a flag used to trigger sample generation, and a special flag used to mark instances used during calculation of sample collections.
\item SAMPLE_COUNT\\
The number of samples in the sample memory belonging to this instance.
\item DISPOSED_GENERATION_COUNT\\
As defined in the \gls{DDS} specification.
\item NO_WRITERS_GENERATION_COUNT\\
As defined in the \gls{DDS} specification.
\item IGNORE_DEADLINE\\
Time until which samples of this instance are dropped (TIME_BASED_FILTER \gls{QOS}).
The special value TIME_INVALID disables this functionality.
This field exists only if TIME_BASED_FILTER \gls{DDS} \gls{QOS} is not set to zero.
\item WRITER_BITMAP\\
A bitmap representing the slots of the \gls{RTPS} Reader endpoint memory.
The WRITER_ID value passed during the ADD_CACHE_CHANGE represents the slot position of the originating writer, and can be used to directly index this array.
A one denotes that the represented writer is actively writing this instance.
\end{itemize}
\begin{lstlisting}[basicstyle=\ttfamily\small,float,captionpos=b,caption={\acrshort{DDS} Reader Payload Data Memory Frame Format},label={lst:dds-reader-payload-data-memory}]
31............24..............16..............8...............0
| | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+---------------------------------------------------------------+
01| NEXT_ADDRESS |
+---------------------------------------------------------------+
02| |
~ PAYLOAD ~
**| |
+---------------------------------------------------------------+
\end{lstlisting}
The associated data of a sample is stored in \emph{Payload Data} memory frames (see \cref{Listing}{lst:dds-reader-payload-data-memory}).
Although the memory frames are fixed size, the payload may have a dynamic size, and may be thus split in multiple linked memory slots.
\subsection{\acrshort{DDS} Writer}
\label{subsec:dds-writer}
The \emph{\gls{DDS} Writer} is responsible for sending user provided data.
As explained above it is also responsible for implementing the \gls{RTPS} HistoryCache, meaning it directly handles \gls{RTPS} Writer operations.
\gls{RTPS} operations are handled with a higher priority over \gls{DDS} operations.
Similar to the \hyperref[subsec:rtps-reader]{\gls{RTPS} Reader} this entity represents all \gls{DDS} Writer endpoints.
This entity contains 3 types of memories: an \emph{instance memory}, a \emph{sample memory}, and a \emph{payload memory} (see \cref{Section}{subsubsec:dds-writer-memory-frame-format} for the memory frame format).
The \emph{instance memory} contains data-instances of provided samples, the \emph{sample memory} contains the sample "meta" data\footnote{One could argue that the \emph{sample memory} does not actually contain \gls{DDS} samples, but \gls{RTPS} CacheChanges.\label{footref:sample-cc-memory}}, and the \emph{payload memory} contains the associated data of the samples (if available).
Each \gls{DDS} Writer has its own set of memories.
The allowed \gls{RTPS} operations are GET_CACHE_CHANGE, ACK_CACHE_CHANGE\footnote{The \gls{DDS} Writer makes no distinction on the configured RELIABILITY \gls{QOS}, and thus depends on the \gls{RTPS} Writer to also ACK \gls{RTPS} CacheChanges when BEST_EFFORT RELIABILITY is used.}, NACK_CACHE_CHANGE, REMOVE_CACHE_CHANGE, GET_MIN_SN, GET_MAX_SN (See \cref{Section}{subsec:rtps-writer}).
The GET_CACHE_CHANGE operation returns the requested \gls{RTPS} CacheChange based on the provided sequence number, whereas the REMOVE_CACHE_CHANGE operation removes the \gls{RTPS} CacheChange from memory.
The ACK_CACHE_CHANGE operation marks the \gls{RTPS} CacheChange based on the provided sequence number as acknowledged, whereas the NACK_CACHE_CHANGE marks the \gls{RTPS} CacheChange as not acknowledged.
The GET_MIN_SN returns the sequence number of the oldest sample in the sample memory (list tail), whereas the GET_MAX_SN returns the sequence number of the newest sample in the sample memory (list head).
%TODO: Move the signal relation description here, since the DDS Writer is the actuator of the operation, or leave it in the RTPS Description to spread the information a bit?
The allowed \gls{DDS} operations are REGISTER_INSTANCE, WRITE, DISPOSE, UNREGISTER_INSTANCE, LOOKUP_INSTANCE, WAIT_FOR_ACKNOWLEDGEMENTS, GET_OFFERED_DEADLINE_MISSED_STATUS, ASSERT_LIVELINESS, GET_LIVELINESS_LOST_STATUS. (see \cref{Timing Diagram}{tim:register-instance}, \cref{Timing Diagram}{tim:write}, \cref{Timing Diagram}{tim:get-offered-deadline-missded-status}, \cref{Timing Diagram}{tim:wait-for-acknowledgements}, and \cref{Timing Diagram}{tim:assert-liveliness}).
These are a subset of the operations defined by the \gls{DDS} specification for a DataReader.
The description of the operations, their inputs, and outputs can be taken directly from the \gls{DDS} specification.
Instances are added to the instance memory either directly through the REGISTER_INSTANCE operation, or indirectly through the WRITE operation with an HANDLE_NIL instance handle.
Similar to the \gls{DDS} Reader, a KEY HOLDER is instantiated for each \gls{DDS} Writer to calculate the instance handle/Key Hash.
If the instance memory is full, the first stale\footnote{An instance is stale if all the associated samples in the sample memory are acknowledged and the instance state is UNREGISTERED.} instance is removed to make space for the new instance.
If no stale instance is available, the operation is rejected.\\
Samples are added with the WRITE, DISPOSE, and UNREGISTER_INSTANCE operations.
Because these operations can be called with instance handle HANDLE_NIL, which means that the instance handle has to be calculated from the provided data before the ACCEPT/REJECT decision for the sample can be made, the memories are extended similar to the \gls{DDS} Reader.
Akin to the \gls{DDS} Reader payload and sample memory unalignment can lead to - depending on the configured \gls{QOS} (see \cref{Table}{tab:dds-writer-max-samples}) - either the operation being rejected, or the oldest (ACKed) sample being removed from the memories.
The behavior on hitting the MAX_SAMPLES and MAX_SAMPLES_PER_INSTANCE RESOURCE_LIMITS \gls{QOS} can be seen in \cref{Table}{tab:dds-writer-max-samples} and \cref{Table}{tab:dds-writer-max-samples-per-instance}, respectively.\\
The operations use the \hyperref[subsec:start-done-interface]{start/done interface}.
The WRITE, DISPOSE, and UNREGISTER_INSTANCE operations also expect valid \emph{instance_handle_in} and \emph{source_ts} signals, whereas the WAIT_FOR_ACKNOWLEDGEMENTS operation expects a valid \emph{max_wait} signal.
The WRITE, DISPOSE, UNREGISTER_INSTANCE, REGISTER_INSTANCE, and LOOKUP_INSTANCE operations are followed by a data transfer of the actual sample payload using the \hyperref[subsec:ready-valid-interface]{read/valid interface} after the acknowledgment of the operations (\emph{ack} signal asserted).
After completion (\emph{done} signal asserted), the GET_* operations initiate a data transfer using \hyperref[subsec:ready-valid-interface]{read/valid interface} for the requested data (see \cref{Listing}{lst:get-offered-deadline-missed-status-format} and \cref{Listing}{lst:get-liveliness-lost-status-format}).
\begin{table}
\centering
\caption{\acrshort{DDS} Writer Behavior on MAX_SAMPLES RESOURCE_LIMIT \gls{QOS}.}
\label{tab:dds-writer-max-samples}
\begin{tabular}{|l|l|}
\hline
\textbf{HISTORY QoS} & \textbf{ACTION}\\
\hline
\multirow{2}{*}{KEEP_ALL} & Remove Oldest ACKed\tablefootnote{If acknowledged Samples are available.\label{footref:acked-sample}} Sample or\\
& Reject Sample\\
\hline
\multirow{2}{*}{KEEP_LAST} & Remove Oldest ACKed\footref{footref:acked-sample} Sample or\\
& Remove Oldest Sample\\
\hline
\end{tabular}
\end{table}
\begin{table}
\centering
\caption{\acrshort{DDS} Reader Behavior on MAX_SAMPLES_PER_INSTANCE RESOURCE_LIMIT \gls{QOS}.}
\label{tab:dds-writer-max-samples-per-instance}
\begin{tabular}{|l|l|}
\hline
\textbf{HISTORY QoS} & \textbf{ACTION}\\
\hline
\multirow{2}{*}{KEEP_ALL} & Remove Oldest ACKed\footref{footref:acked-sample} Instance Sample or\\
& Reject Sample\\
\hline
\multirow{2}{*}{KEEP_LAST} & Remove Oldest ACKed\footref{footref:acked-sample} Instance Sample or\\
& Remove Oldest Instance Sample\\
\hline
\end{tabular}
\end{table}
\subsubsection{Memory Frame Format}
\label{subsubsec:dds-writer-memory-frame-format}
\begin{lstlisting}[basicstyle=\ttfamily\small,float,captionpos=b,caption={\acrshort{DDS} Writer Sample Data Memory Frame Format},label={lst:dds-writer-sample-data-memory}]
31............24..............16..............8...............0
| | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+---------------------------------------------------------------+
01| STATUS_INFO |
+---------------------------------------------------------------+
02| |
+ SEQ_NR +
03| |
+---------------------------------------------------------------+
04| |
+ TIMESTAMP +
05| |
+---------------------------------------------------------------+
06| |
+ LIFESPAN_DEADLINE +
07| [only if LIFESPAN /= INFINITE] |
+---------------------------------------------------------------+
08| PAYLOAD_ADDRESS |
+---------------------------------------------------------------+
09| INSTANCE_ADDRESS [only if WITH_KEY] |
+---------------------------------------------------------------+
10| PREV_ADDRESS |
+---------------------------------------------------------------+
11| NEXT_ADDRESS |
+---------------------------------------------------------------+
STATUS INFO
-----------
31............24..............16..............8...............0
| | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+---------------------------------------------------+-+-+-+
|R|P|A| UNUSED |F|U|D|
+-+-+-+---------------------------------------------------+-+-+-+
R...Sample has been ACKed
P...Sample has associated DATA Payload
A...Associated Payload is aligned (Payload does extend until end of last Palyload Slot)
F...FilteredFlag (1:1 PID_STATUS_INFO Mapping)
U...UnregisteredFlag (1:1 PID_STATUS_INFO Mapping)
D...DisposedFlag (1:1 PID_STATUS_INFO Mapping)
\end{lstlisting}
The meta-information of \gls{RTPS} CacheChanges\footref{footref:sample-cc-memory} is stored in \emph{Sample Data} memory frames (see \cref{Listing}{lst:dds-writer-sample-data-memory}).
The memory frame fields are explained below:
\begin{itemize}
\item STATUS_INFO\\
Flags that specify if the \gls{RTPS} CacheChange has been ACKed, if the \gls{RTPS} CacheChange has an associated payload, if the associated payload is aligned to the end of the memory slots, and what kind the \gls{RTPS} CacheChange is (Filter, Unregister, Dispose).
\item SEQ_NR\\
The unique\footnote{In relation to \gls{RTPS} CacheChanges generated by this Writer.} sequence number of the \gls{RTPS} CacheChange.
\item TIMESTAMP\\
The creation\footnote{The user can override the timestamp with a custom defined one.} timestamp of the \gls{RTPS} CacheChange.
\item LIFESPAN_DEADLINE\\
The time after which the sample is considered obsolete and will be removed.
This field exists only if LIFESPAN \gls{DDS} \gls{QOS} is not set to INFINITE.
\item PAYLOAD_ADDRESS\\
The memory address of the associated payload.
\item INSTANCE_ADDRESS\\
The memory address of the associated data-instance.
This field exists only if the local reader endpoint is configured for keyed topics (WITH_KEY attribute true).
\end{itemize}
\begin{lstlisting}[basicstyle=\ttfamily\small,float,captionpos=b,caption={\acrshort{DDS} Writer Instance Data Memory Frame Format},label={lst:dds-writer-instance-data-memory}]
31............24..............16..............8...............0
| | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+---------------------------------------------------------------+
01| NEXT_ADDRESS |
+---------------------------------------------------------------+
02| PREV_ADDRESS |
+---------------------------------------------------------------+
03| |
+ +
04| |
+ KEY_HASH +
05| |
+ +
06| |
+---------------------------------------------------------------+
07| STATUS_INFO |
+---------------------------------------------------------------+
08| SAMPLE_COUNT |
+---------------------------------------------------------------+
09| ACK_COUNT |
+---------------------------------------------------------------+
STATUS INFO
-----------
31............24..............16..............8...............0
| | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+---------------------------------------------------------+-+-+-+
| UNUSED |L|U|D|
+---------------------------------------------------------+-+-+-+
D...DISPOSED
W...UNREGISTERED
L...LIVELINESS FLAG
\end{lstlisting}
The instance information of samples is stored in \emph{Instance Data} memory frames (see \cref{Listing}{lst:dds-writer-instance-data-memory}).
The memory frame fields are explained below:
\begin{itemize}
\item KEY_HASH\\
The Key Hash/Instance Handle of the instance.
\item STATUS_INFO\\
Flags defining the instance state (ALIVE, NOT_ALIVE_DISPOSED, NOT_ALIVE_NO_WRITERS), and a liveliness flag used for the DEADLINE \gls{QOS}.
\item SAMPLE_COUNT\\
The number of samples in the sample memory belonging to this instance.
\item ACK_COUNT\\
The number of samples belonging to this instance that have been acknowledged.
\end{itemize}
\begin{lstlisting}[basicstyle=\ttfamily\small,float,captionpos=b,caption={\acrshort{DDS} Writer Payload Data Memory Frame Format},label={lst:dds-writer-payload-data-memory}]
31............24..............16..............8...............0
| | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+---------------------------------------------------------------+
01| NEXT_ADDRESS |
+---------------------------------------------------------------+
02| |
~ PAYLOAD ~
**| |
+---------------------------------------------------------------+
\end{lstlisting}
\subsection{Reader/Writer Interface}
\label{subsec:dds-intereface}
The <TYPENAME>_READER_INTERFACE and <TYPENAME>_WRITER_INTERFACE wrap the \gls{DDS} Reader and \gls{DDS} Writer entities, respectively.
They latch all type-defined components in registers/memories and map them directly to entity ports, which the user can interface directly.
The <TYPENAME>_READER_INTERFACE fills the registers/memories with the payloads fetched from the \gls{DDS} Reader, whereas the <TYPENAME>_WRITER_INTERFACE uses the user filled registers/memories to produce an \gls{RTPS} complaint payload and push it to the \gls{DDS} Writer.\\
In essence the type interfaces sit between the \gls{DDS} Entities and the user, and just encode/decode the \gls{RTPS} payloads and flatten them to port mappings.
The signal interaction with the wrappers is essentially the same as with the \gls{DDS} entities themselves, but with some exceptions.
When requesting/writing data from samples, only the \emph{<TYPENAME_SIGNALS>} are used and no direct data transfer using the \hyperref[subsec:ready-valid-interface]{ready/valid interface} is initiated\footnote{Note that non payload-data related \gls{DDS} Operations (like GET_REQUESTED_DEADLINE_MISSED_STATUS) still require the direct use of the data transfer signals.}.\\
For the reader interface, once the data is requested, it stays valid (\emph{<TYPENAME>_valid} signal asserted) until the next time data is requested\footnote{Which may not happen on the same \gls{DDS} Operation.\label{footref:same-dds-operation}}.
Similarly, if a decode error happens (e.g. Unsupported Payload Format), the \emph{decode_error} signal is asserted until the next data is requested\footref{footref:same-dds-operation}.\\
For the writer interface the \emph{<TYPENAME>_signals} have to be held valid\footnote{The memories have to be filled with the respective data prior to the start of the \gls{DDS} Operation.} until the \emph{encode_done} signal is asserted.\\
\cref{Timing Diagram}{tim:interface-read}, \cref{Timing Diagram}{tim:interface-read-decode-error}, \cref{Timing Diagram}{tim:interface-read-next-sample}, \cref{Timing Diagram}{tim:interface-read-next-sample-decode-error}, \cref{Timing Diagram}{tim:interface-read-instance}, and \cref{Timing Diagram}{tim:interface-get-sample-rejected-status} show the signal relations of the Reader Interface, whereas \cref{Timing Diagram}{tim:interface-register-instance}, \cref{Timing Diagram}{tim:interface-write}, \cref{Timing Diagram}{tim:interface-get-offered-deadline-missded-status}, \cref{Timing Diagram}{tim:interface-wait-for-acknowledgements}, and \cref{Timing Diagram}{tim:interface-assert-liveliness} show the signal relations of the Writer Interface.
A port/register/memory mapping for all possible \gls{IDL} type definitions\footnote{As defined by the \gls{DDS-XTYPES} Specification \cite{dds-xtypes}.\label{footref:dds-xtypes}} is made.
In general, \emph{primitive types}\footref{footref:dds-xtypes} directly map to registers of equal size, and \emph{collection types}\footref{footref:dds-xtypes} (Arrays, Sequences, Maps) map to memories of equal width, and depth equal to the maximum length\footnote{Even for types with no directly specified upper bound, an indirect system wide upper bound has to be specified due to physical resource constraints.}, and the memory interface signals are presented to the user (see \cref{Timing Diagram}{tim:reader-interface-array} and \cref{Timing Diagram}{tim:writer-interface-array}).
\emph{Nested types} ares distinguished by a port-naming convention\footnote{<OUTER-TYPENAME>_<NESTED-TYPENAME>.}.
Nested collection types map to arrays of memories, and the address of the outer collection defines which nested memories are addressed.
\emph{Optional type members}\footref{footref:dds-xtypes} get an extra \emph{<MEMBERNAME>_opt} signal, which is asserted when the optional member is defined/valid.
Currently \emph{MUTABLE Extensibility}\footref{footref:dds-xtypes}, as well as optional type members with no fixed-size (e.g. sequences) are not supported.
The type interfaces currently only support \emph{PLAIN_CDR} encoding of \emph{encoding version 1}\footref{footref:dds-xtypes}.
\cref{Listing}{lst:type1-idl} shows an example \gls{IDL} definition of a type, and \cref{Listing}{lst:type1-reader-interface} and \cref{Listing}{lst:type1-writer-interface} show the generated \gls{VHDL} entity port definitions of the reader and writer interface, respectively.
The generation of the interface wrappers is thought to be performed automatically by a code generator taking the \gls{IDL} type definitions as input, but the code generator was not implemented as part of this work.
Instead template \gls{VHDL} files containing boilerplate code and a "cookbook"\footnote{The template files and cookbook are laid out in a way to a allow a code generator to be implemented directly based on them.} defining how the template files are to be extended based on the provided \gls{IDL} definitions, allowing manual generation of the required files.
\begin{lstlisting}[basicstyle=\ttfamily\tiny,float,captionpos=b,caption={Example \acrshort{IDL} Topic Type Definition.},label={lst:type1-idl},language={[CORBA]IDL},morekeywords={bitmask,@extensibility,@nested,@bit_bound,@key,@optional,@topic,@position}]
@extensibility(FINAL) @nested
union TestUnion_t switch (char) {
case 'a':
long LongU;
default:
octet OctetU;
};
@bit_bound(9)
bitmask TestBitmask_t {
@position(0) POS1,
@position(3) POS3,
@position(4) POS4
};
@bit_bound(7)
enum TestEnum_t {
A,
B,
C,
D
};
typedef octet TestArray_t[5];
@extensibility(FINAL) @nested
struct NestedStruct_t {
@key TestArray_t TestArray;
char TestChar;
wchar TestWChar;
long long TestLongLong;
@optional long double TestLongDouble;
};
typedef sequence<NestedStruct_t, 4> TestSequence_t;
typedef string<12> TestString_t;
typedef TestMap_t map<octet, short, 4>;
@extensibility(FINAL) @topic
struct Type1 {
@key long id;
@key TestSequence_t TestSequence;
TestMap_t TestMap;
TestEnum_t TestEnum;
@optional TestUnion_t TestUnion;
TestBitmask_t TestBitmask;
TestString_t TestString;
};
\end{lstlisting}
\begin{lstlisting}[basicstyle=\ttfamily\tiny,float,captionpos=b,caption={Reader Interface Port Definition of Type1},label={lst:type1-reader-interface},language=VHDL,commentstyle=\color{ForestGreen}]
entity Type1_reader_interface is
port (
[...]
-- ###GENERATED START###
id : out std_logic_vector(CDR_LONG_WIDTH-1 downto 0);
TestSequence_len : out std_logic_vector(TESTSEQUENCE_ADDR_WIDTH-1 downto 0);
TestSequence_addr : in std_logic_vector(TESTSEQUENCE_ADDR_WIDTH-1 downto 0);
TestSequence_ready : out std_logic;
TestSequence_ren : in std_logic;
TestSequence_valid : out std_logic;
TestSequence_ack : in std_logic;
TestSequence_TestArray_addr : in std_logic_vector(TESTSEQUENCE_TESTARRAY_ADDR_WIDTH-1 downto 0);
TestSequence_TestArray_ready : out std_logic;
TestSequence_TestArray_ren : in std_logic;
TestSequence_TestArray_valid : out std_logic;
TestSequence_TestArray_ack : in std_logic;
TestSequence_TestArray : out std_logic_vector(CDR_OCTET_WIDTH-1 downto 0);
TestSequence_TestChar : out std_logic_vector(CDR_CHAR_WIDTH-1 downto 0);
TestSequence_TestWChar : out std_logic_vector(CDR_WCHAR_WIDTH-1 downto 0);
TestSequence_TestLongLong : out std_logic_vector(CDR_LONG_LONG_WIDTH-1 downto 0);
TestSequence_TestLongDouble : out std_logic_vector(CDR_LONG_DOUBLE_WIDTH-1 downto 0);
TestSequence_TestLongDouble_opt : out std_logic;
TestMap_len : out std_logic_vector(TESTMAP_ADDR_WIDTH-1 downto 0);
TestMap_addr : in std_logic_vector(TESTMAP_ADDR_WIDTH-1 downto 0);
TestMap_ready : out std_logic;
TestMap_ren : in std_logic;
TestMap_valid : out std_logic;
TestMap_ack : in std_logic;
TestMap_key : out std_logic_vector(CDR_OCTET_WIDTH-1 downto 0);
TestMap_value : out std_logic_vector(CDR_SHORT_WIDTH-1 downto 0);
TestEnum : out std_logic_vector(TESTENUM_WIDTH-1 downto 0);
TestUnion_opt : out std_logic;
TestUnion_d : out std_logic_vector(CDR_CHAR_WIDTH-1 downto 0);
TestUnion_LongU : out std_logic_vector(CDR_LONG_WIDTH-1 downto 0);
TestUnion_OctetU : out std_logic_vector(CDR_OCTET_WIDTH-1 downto 0);
TestBitmask : out std_logic_vector(TESTBITMASK_WIDTH-1 downto 0);
TestString_len : out std_logic_vector(TESTSTRING_ADDR_WIDTH-1 downto 0);
TestString_addr : in std_logic_vector(TESTSTRING_ADDR_WIDTH-1 downto 0);
TestString_ready : out std_logic;
TestString_ren : in std_logic;
TestString_valid : out std_logic;
TestString_ack : in std_logic;
TestString : out std_logic_vector(CDR_CHAR_WIDTH-1 downto 0);
-- ###GENERATED END###
valid : out std_logic;
decode_error : out std_logic
);
end entity;
\end{lstlisting}
\begin{lstlisting}[basicstyle=\ttfamily\tiny,float,captionpos=b,caption={Writer Interface Port Definition of Type1},label={lst:type1-writer-interface},language=VHDL,commentstyle=\color{ForestGreen}]
entity Type2_writer_interface is
generic (
LITTLE_ENDIAN : std_logic := '0'
);
port (
[...]
-- ###GENERATED START###
id : in std_logic_vector(CDR_LONG_WIDTH-1 downto 0);
TestSequence_len : in std_logic_vector(TESTSEQUENCE_ADDR_WIDTH-1 downto 0);
TestSequence_addr : in std_logic_vector(TESTSEQUENCE_ADDR_WIDTH-1 downto 0);
TestSequence_ready : out std_logic;
TestSequence_ren : in std_logic;
TestSequence_wen : in std_logic;
TestSequence_valid : out std_logic;
TestSequence_ack : in std_logic;
TestSequence_TestArray_addr : in std_logic_vector(TESTSEQUENCE_TESTARRAY_ADDR_WIDTH-1 downto 0);
TestSequence_TestArray_ready : out std_logic;
TestSequence_TestArray_ren : in std_logic;
TestSequence_TestArray_wen : in std_logic;
TestSequence_TestArray_valid : out std_logic;
TestSequence_TestArray_ack : in std_logic;
TestSequence_TestArray_r : out std_logic_vector(CDR_OCTET_WIDTH-1 downto 0);
TestSequence_TestArray_w : in std_logic_vector(CDR_OCTET_WIDTH-1 downto 0);
TestSequence_TestChar_r : out std_logic_vector(CDR_CHAR_WIDTH-1 downto 0);
TestSequence_TestChar_w : in std_logic_vector(CDR_CHAR_WIDTH-1 downto 0);
TestSequence_TestWChar_r : out std_logic_vector(CDR_WCHAR_WIDTH-1 downto 0);
TestSequence_TestWChar_w : in std_logic_vector(CDR_WCHAR_WIDTH-1 downto 0);
TestSequence_TestLongLong_r : out std_logic_vector(CDR_LONG_LONG_WIDTH-1 downto 0);
TestSequence_TestLongLong_w : in std_logic_vector(CDR_LONG_LONG_WIDTH-1 downto 0);
TestSequence_TestLongDouble_r : out std_logic_vector(CDR_LONG_DOUBLE_WIDTH-1 downto 0);
TestSequence_TestLongDouble_w : in std_logic_vector(CDR_LONG_DOUBLE_WIDTH-1 downto 0);
TestSequence_TestLongDouble_opt_r : out std_logic;
TestSequence_TestLongDouble_opt_w : in std_logic;
TestMap_len : in std_logic_vector(TESTMAP_ADDR_WIDTH-1 downto 0);
TestMap_addr : in std_logic_vector(TESTMAP_ADDR_WIDTH-1 downto 0);
TestMap_ready : out std_logic;
TestMap_ren : in std_logic;
TestMap_wen : in std_logic;
TestMap_valid : out std_logic;
TestMap_ack : in std_logic;
TestMap_key_r : out std_logic_vector(CDR_OCTET_WIDTH-1 downto 0);
TestMap_key_w : in std_logic_vector(CDR_OCTET_WIDTH-1 downto 0);
TestMap_value_r : out std_logic_vector(CDR_SHORT_WIDTH-1 downto 0);
TestMap_value_w : in std_logic_vector(CDR_SHORT_WIDTH-1 downto 0);
TestEnum : in std_logic_vector(TESTENUM_WIDTH-1 downto 0);
TestUnion_opt : in std_logic;
TestUnion_d : in std_logic_vector(CDR_CHAR_WIDTH-1 downto 0);
TestUnion_LongU : in std_logic_vector(CDR_LONG_WIDTH-1 downto 0);
TestUnion_OctetU : in std_logic_vector(CDR_OCTET_WIDTH-1 downto 0);
TestBitmask : in std_logic_vector(TESTBITMASK_WIDTH-1 downto 0);
TestString_len : in std_logic_vector(TESTSTRING_ADDR_WIDTH-1 downto 0);
TestString_addr : in std_logic_vector(TESTSTRING_ADDR_WIDTH-1 downto 0);
TestString_ready : out std_logic;
TestString_ren : in std_logic;
TestString_wen : in std_logic;
TestString_valid : out std_logic;
TestString_ack : in std_logic;
TestString_r : out std_logic_vector(CDR_CHAR_WIDTH-1 downto 0);
TestString_w : in std_logic_vector(CDR_CHAR_WIDTH-1 downto 0);
-- ###GENERATED END###
encode_done : out std_logic
);
end entity;
\end{lstlisting}
\subsection{Key Holder}
\label{subsec:key-holder}
The \emph{Key Holder} holds the \gls{DDS} topic key\footnote{\gls{IDL} type members marked with the \emph{@key} annotation.} and is used to generate a serialized key for \gls{RTPS} DATA Submessage payloads or the \hyperref[par:key-hash]{\gls{RTPS} Key Hash}.
This entity uses the \hyperref[subsec:start-done-interface]{start/done interface} for operations together with the \hyperref[subsec:ready-valid-interface]{read/valid interface} for data transfers, and can be filled either with a "complete" data payload, or an \gls{RTPS} serialized key\footnote{The \gls{RTPS} Specification surprisingly does not define what a serialized key is. This work will follow the lead of other implementations and define it as the striped down "KeyHolder" Object used for the \gls{RTPS} Key Hash calculation.}.
The allowed operations are PUSH_DATA, PUSH_SERIALIZED_KEY, READ_KEY_HASH, READ_SERIALIZED_KEY (see \cref{Timing Diagram}{tim:key-holder-push-data}, \cref{Timing Diagram}{tim:key-holder-decode-error}, \cref{Timing Diagram}{tim:key-holder-abort}, and \cref{Timing Diagram}{tim:key-holder-read-key-hash}).
The Key Holder contains a subset of the encoding and decoding stages of the reader and writer interfaces and stores key data in registers/memories similar to the reader/writer interfaces, but does not directly expose them to the outside.
The Key Holder instantiates internally a \emph{Key Hash Generator} that takes the serialized key as input and calculates the \gls{RTPS} Key Hash.
\section{\acrshort{ROS}}
\label{sec:impl-ros}
\gls{ROS} uses a different time representation than \gls{RTPS}/\gls{DDS}\footnote{Whereas \gls{RTPS}/\gls{DDS} uses a 64-bit seconds value in 32Q32 fixed point format, \gls{ROS} uses a 32-bit seconds and 32-bit nanoseconds value.}.
A \emph{ros_time_converter} is defined, which converts system time (which is in \gls{RTPS}/\gls{DDS} Format) to the \gls{ROS} time format.
Due to the way \gls{ROS} maps nodes to \gls{DDS} entities\cite{ros2-node-mapping}, an additional \gls{DDS} topic has to be published by each \gls{DDS} participant, that helps map the \gls{DDS} endpoints to \gls{ROS} nodes.
For this purpose the \emph{ros_static_discovery_writer} was implemented, which is a specialized \gls{DDS} writer only publishing one statically generated sample.
Similar to the \gls{DDS} \hyperref[subsec:dds-intereface]{Reader/Writer Interfaces}, \gls{ROS} is also implemented using \gls{VHDL} interfaces generated through \gls{IDL} files.
Since the transition to using \gls{DDS} as middleware, \gls{ROS} provides tools that generate \gls{IDL} files from \texttt{.msg}, \texttt{.srv}, and \texttt{.action} files described in \cref{Section}{subsec:computation_graph_model}.
This allows the use of the previously defined \gls{IDL}-to-\gls{VHDL} mapping with minor adjustments.
Unfortunately the translation of \gls{ROS} functionality to \gls{DDS} functionality is ambiguous and not defined in a standard, which leads to multiple vendors having incompatible \gls{ROS} level functionality (although the underlying \gls{DDS} implementations are interoperable).
This work used \emph{Galactic Geochelone} \gls{ROS} release as implementation reference, which uses \emph{Eclipse Cyclone DDS}\cite{cyclone-dds} as the default middleware.
Thus this work will adopt the \gls{ROS} functionality as implemented by Eclipse Cyclone DDS.
\cref{Figure}{fig:ros-action-architecture-overview} shows the complete system architecture overview of an \gls{ROS} action server, which showcases all available \gls{ROS} components.\\
\begin{figure}[htp]
\centering
\includegraphics[width=\textwidth]{graphics/system_overview-ROS_ACTION.pdf}
\caption{\acrshort{RTPS}/\acrshort{DDS} Architecture Overview}
\label{fig:ros-action-architecture-overview}
\end{figure}
\subsection{\acrshort{ROS} Topic}
\label{subsec:impl-ros-topic}
A \texttt{<MESSAGENAME>.msg} file, which defines a \gls{ROS} topic, is translated to \gls{IDL}, and 2 \gls{VHDL} interfaces are generated, a \emph{<MESSAGENAME>_ros_sub} representing a \gls{ROS} subscriber, and a \emph{<MESSAGENAME>_ros_pub} representing a \gls{ROS} publisher.
Both files are almost verbatim copies of their <TYPENAME>_reader_interface and <TYPENAME>_writer_interface counterparts, with the exception of hiding all user facing \gls{DDS} signals and instead being responsible to interact with the \gls{DDS} endpoint directly.
Similar to the Reader/Writer interfaces, \gls{VHDL} template files containing the boilerplate code are provided.
The template files are extended with generated code based on the \gls{IDL}-to-\gls{VHDL} mapping defined previously.
The allowed operation of the <MESSAGENAME>_ros_sub is TAKE (see \cref{Timing Diagram}{tim:ros-take}).
The \hyperref[subsec:start-done-interface]{start/done interface} is used for the operation, but in opposition to a <TYPENAME>_reader_interface directly requests the sample data, and returns (\emph{done} signal asserted) after the data has been decoded\footnote{Or returns an error code in the \emph{return_code} signal on decode error.}.
The \emph{taken} signal is asserted whenever data was taken from the \gls{DDS} endpoint (If the \emph{taken} signal is not asserted, no payload data was returned from the \gls{DDS} Endpoint).
The \emph{data_available} signal is asserted whenever data is available on the \gls{DDS} endpoint, but due to an implementation detail the signal stays asserted until the first TAKE operation returns "empty".
This means that an additional obsolete TAKE operation needs to be done every time the \emph{data_available} signal is asserted.
In addition to the message dependent port signals, the \gls{ROS} defined \emph{message_info} signal provides additional information, like the message source timestamp, reception timestamp, the \gls{GID}\footnote{\gls{ROS} uses a 24-Byte \gls{GID}, which currently is implemented as a padded \gls{RTPS}/\gls{DDS} \gls{GUID}.} of the \gls{DDS} Publisher, and if the message is coming from intra-process\footnote{Messages sent directly via in-process memory.} communication.
The allowed operation of the <MESSAGENAME>_ros_pub is PUBLISH (see \cref{Timing Diagram}{tim:ros-publish}).
The \hyperref[subsec:start-done-interface]{start/done interface} is used for the operation, and the message dependent signals have to be held valid until the operation is completed (\emph{done} signal asserted).
\subsection{\acrshort{ROS} Service}
\label{subsec:impl-ros-service}
A \texttt{<SERVICENAME>.srv} file, which defines a \gls{ROS} service, is translated to \gls{IDL}, and 2 \gls{VHDL} interfaces are generated, a \emph{<SERVICENAME>_ros_srv_client} representing a \gls{ROS} Service client, and a \emph{<SERVICENAME>_ros_srv_client} representing a \gls{ROS} Service server.
Similar to the Key Holder, both generated files contain both encoding and decoding functionality, with extra logic used to handle the \emph{request header} that is prepended to the payload.
Like before, the \gls{VHDL} template files contain the boilerplate code, and are extended with generated code based on the previously defined \gls{IDL}-to-\gls{VHDL} mapping.
The allowed operations of the <SERVICENAME>_ros_srv_client are SEND_REQUEST, TAKE_RESPONSE (see \cref{Timing Diagram}{tim:ros-send-request} and \cref{Timing Diagram}{tim:ros-take-response}).\\
The allowed operations of the <SERVICENAME>_ros_srv_server are TAKE_REQUEST, SEND_RESPONSE (see \cref{Timing Diagram}{tim:ros-take-request} and \cref{Timing Diagram}{tim:ros-send-response}).\\
Both the <SERVICENAME>_ros_srv_client and the <SERVICENAME>_ros_srv_server use the \hyperref[subsec:start-done-interface]{start/done interface} for operations and behave in essence like a combined \gls{ROS} Subscriber and Publisher.\\
The <SERVICENAME>_ros_srv_client provides the user with an additional \emph{sequence_id} signal, which is incremented on each sent request and is used to identify the responses, and a \emph{service_info} signal, which contains the source timestamp, the reception timestamp, and the \emph{request_id}\footnote{The request_id contains the sequence_id and the \gls{GUID} of the writer initiating the service request.} of the response.\\
The <SERVICENAME>_ros_srv_server reverses the input and output signals, provides a \emph{service_info} signal on the TAKE_REQUEST operation, and requires a \emph{request_id} signal on the SEND_RESPONSE operation.
\subsection{\acrshort{ROS} Action}
\label{subsec:impl-ros-action}
\gls{ROS} Actions are implemented a layer above \gls{ROS} Topics and \gls{ROS} Services, and are implemented using 3 \gls{ROS} Services (GOAL, RESULT, CANCEL), and 2 \gls{ROS} Topics (FEEDBACK, STATUS\footnote{The STATUS \gls{ROS} Topic is used for introspection and is not used by the \gls{ROS} Action client directly.}).
From those the CANCEL \gls{ROS} Service and STATUS \gls{ROS} Topic are static and do not depend on the respective action type, whereas the GOAL \gls{ROS} Service, RESULT \gls{ROS} Service, and FEEDBACK \gls{ROS} Topic are defined by the \texttt{<ACTIONNAME>.action} file.\\
In summary a \gls{ROS} Action is implemented using following files:
\begin{itemize}
\item <ACTIONNAME>_ros_action_goal_srv_server (Generated)
\item <ACTIONNAME>_ros_action_goal_srv_client (Generated)
\item CancelGoal_ros_srv_server (Static)
\item CancelGoal_ros_srv_client (Static)
\item <ACTIONNAME>_ros_action_result_srv_server (Generated)
\item <ACTIONNAME>_ros_action_result_srv_client (Generated)
\item <ACTIONNAME>_ros_action_feedback_pub (Generated)
\item <ACTIONNAME>_ros_action_feedback_sub (Generated)
\item GoalStatusArray_ros_pub (Static)
\item GoalStatusArray_ros_sub (Static)
\item <ACTIONNAME>_ros_action_server (Generated)
\item <ACTIONNAME>_ros_action_client (Generated)
\item ros_action_server (Static)
\end{itemize}
The generation of the files follows the methods used for \gls{ROS} Topics and \gls{ROS} Services, and \gls{VHDL} template files are provided for each topic/service, and contain optimized code\footnote{The Goal \gls{ID}, for instance, even though defined as a Byte array, is directly implemented as a 128-bit integer.} for the static parts of the \gls{ROS} topics/services.
\subsubsection{\acrshort{ROS} Action Client}
\label{subsubsec:impl-ros-action-client}
The <ACTIONNAME>_ros_action_client implements the \gls{ROS} Action Client and is a lightweight wrapper responsible for instantiating and interfacing the underlying GOAL \gls{ROS} Service client (<ACTIONNAME>_ros_action_goal_srv_client), RESULT \gls{ROS} Service client (<ACTIONNAME>_ros_action_result_srv_client), CANCEL \gls{ROS} Service client (CancelGoal_ros_srv_client), and FEEDBACK \gls{ROS} Topic Subscriber (<ACTIONNAME>_ros_action_feedback_sub).
The allowed operations of the <ACTIONNAME>_ros_action_client are SEND_GOAL_REQUEST, TAKE_GOAL_RESPONSE, SEND_RESULT_REQUEST, TAKE_RESULT_RESPONSE, SEND_CANCEL_REQUEST, TAKE_CANCEL_RESPONSE, and TAKE_FEEDBACK (see \cref{Timing Diagram}{tim:ros-action-client-goal}, \cref{Timing Diagram}{tim:ros-action-client-result}, \cref{Timing Diagram}{tim:ros-action-client-cancel}, and \cref{Timing Diagram}{tim:ros-action-client-feedback}).
The signals and their interaction and relation is the same as for the <SERVICENAME>_ros_srv_client and <MESSAGENAME>_ros_sub entities, with the main exception being the absence of the \emph{taken} signal.
Instead the last "empty" take operation that resets the respective \emph{data_available_*} signal is returning a \emph{NOK} (Not OK) return code in the \emph{return_code} signal.
\subsubsection{\acrshort{ROS} Action Server}
\label{subsubsec:impl-ros-action-server}
The <ACTIONNAME>_ros_action_server implements the \gls{ROS} Action Server and is a wrapper responsible for instantiating and interfacing the underlying GOAL \gls{ROS} Service server (<ACTIONNAME>_ros_action_goal_srv_server), RESULT \gls{ROS} Service server (<ACTIONNAME>_ros_action_result_srv_server), CANCEL \gls{ROS} Service server (CancelGoal_ros_srv_server), FEEDBACK \gls{ROS} Topic Publisher (<ACTIONNAME>_ros_action_feedback_pub), STATUS \gls{ROS} Topic Publisher (GoalStatusArray_ros_pub), and the actual \gls{ROS} action server (ros_action_server).\\
Even though the \gls{ROS} Topic and \gls{ROS} Service implementations are based on the \gls{ROS} \gls{RMW} \gls{API}, \gls{ROS} Actions are not defined in the \gls{RMW} layer, but only in the \gls{RCL} layer, which is one layer above the \gls{RMW} layer.
The \gls{ROS} Action client interface follows the \gls{RCL} \gls{API}, which just presents the underlying \gls{ROS} Service and \gls{ROS} Topic interfaces to the user, since there is nothing extra that the \gls{ROS} Action client has to do.
The \gls{ROS} Action server on the other hand is more involved than the client side, since the server must simultaneously track multiple goals and result requests from clients, interpret cancel requests\footnote{Since the cancel request can specify goals accepted in a specific time frame.}, publish on the STATUS \gls{ROS} Topic whenever the tracked goal list is modified, and cache goal results.
This additional logic is supposed to be done on the layer above the \gls{RCL} \gls{API}, and thus a custom \gls{ROS} Action server interface was implemented.
This additional logic is not type dependent and is contained in the ros_action_server \gls{VHDL} file.
The <ACTIONNAME>_ros_action_server has to present the type dependent signals next to the signals from the ros_action_server to the user, and also contains a "memory array" for storing the results of the tracked/stored goals, to which the user has direct access to\footnote{The ros_action_server logic is never directly coming into contact with the actual goal results.}.\\
The ros_action_server contains 2 memories, a \emph{goal memory}, and a \emph{result request memory} (see \cref{Section}{par:ros-action-server-memory-frame-format} for the memory frame format).
The \emph{goal memory} is for storing and tracking the accepted goals from the GOAL \gls{ROS} Service, and the \emph{result request memory} is for storing result requests that cannot be yet serviced from the RESULT \gls{ROS} Service.
The user is presented with \emph{goal handles} which represent goal stored in memory and are used to interact with the server.\\
Whenever the GOAL service has available data, the goal request is fetched and presented to the user (\emph{new_goal_request} signal asserted, \emph{new_goal_handle} signal containing the goal handle of the new goal, and \emph{new_goal_result_index} signal containing the target memory address/index of the result array for this goal).
The server waits until the user asserts the \emph{new_goal_response} signal, and the \emph{new_goal_accepted} signal denotes if the user accepted (signal asserted) or rejected the goal request, and the GOAL \gls{ROS} Service response is sent accordingly.\\
%REF:If the goal memory is full and the TIMEOUT_DURATION generic is set to infinite duration, the entity will remove the oldest stored goal in a terminal state, if a new goal request is available from the GOAL service. If on the other hand the the TIMEOUT_DURATION is set, the goal will be automatically removed by the configured duration after the goal enters a terminal state.
Whenever the RESULT service has available data, the result request is fetched and handled.
If the target goal is not stored in the memory or the goal has already entered a terminal state, the RESULT \gls{ROS} Service response is sent immediately.
If the target goal has not yet entered a terminal state, the result request is stored in the result request memory.
Whenever a goal enters a terminal state, the stored result requests of the respective goal are handled and removed
from the memory.\\
Whenever the CANCEL service has available data, the cancel request is fetched, and all relevant goal cancellation requests are presented to the user (\emph{cancel_request} signal asserted, and \emph{cancel_request_handle} signal contains the goal handle of the goal to be canceled).
The server waits until the user asserts the \emph{cancel_response} signal, and the \emph{cancel_accepted} signal denotes if the user accepted (signal asserted) or rejected the cancellation request, and the CANCEL \gls{ROS} service response is sent accordingly.
The allowed operations of the <ACTIONNAME>_ros_action_server are GET_GOAL, GET_LAST_GOAL, GET_FIRST_GOAL, GET_NEXT_GOAL, GET_PREVIOUS_GOAL, UPDATE_GOAL_STATE, PUBLISH_FEEDBACK (see \cref{Timing Diagram}{tim:ros-action-server-user}, \cref{Timing Diagram}{tim:ros-action-server-get-first-goal}, \cref{Timing Diagram}{tim:ros-action-server-get-goal}, \cref{Timing Diagram}{tim:ros-action-server-update-goal-state}, and \cref{Timing Diagram}{tim:ros-action-server-publish-feedback}).
The operations use the \hyperref[subsec:start-done-interface]{start/done interface}.
The GET_GOAL operation allows the user to get the goal \gls{ID}, the current goal state, the target memory address/index of the result array, the goal acceptance timestamp, and the goal handle of a particular goal denoted by the goal handle in the \emph{goal_handle_in}, in the \emph{goal_id}, \emph{goal_state_out}, \emph{goal_result_index}, \emph{goal_stamp}, and \emph{goal_handle_out} signals, respectively.
Similarly the GET_FIRST_GOAL and GET_LAST_GOAL operations return the oldest and newest accepted goal in the list, whereas the GET_NEXT_GOAL and GET_PREVIOUS_GOAL operations return the next and previous goal based on the goal handle provided in the \emph{goal_handle_in} signal, and can be used to iterate through the stored goal list.
The UPDATE_GOAL_STATE operation is used to update the goal state of the goal denoted by the goal handle in the \emph{goal_handle_in} signal to the state provided in the \emph{goal_state_in} signal.
When transitioning to the "SUCCEEDED" state the user has to make sure, that the goal results are stored in the respective memory address/index of the result array prior to the start of the operation.
The PUBLISH_FEEDBACK operation triggers the server to publish in the feedback topic and is used to publish feedback for the goal denoted by the goal handle in the \emph{goal_handle_in} signal.
The user has to hold the type-dependent feedback signals valid until the return of the operation.
\paragraph{Memory Frame Format}
\label{par:ros-action-server-memory-frame-format}
\begin{lstlisting}[basicstyle=\ttfamily\small,float,captionpos=b,caption={\acrshort{ROS} Action Server Goal Data Memory Frame Format},label={lst:ros-action-server-goal-data-memory}]
31............24..............16..............8...............0
| | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-----------------------------------------------+---------------+
01| UNUSED | GOAL_STATE |
+-----------------------------------------------+---------------+
02| |
+ +
03| |
+ GOAL_ID +
04| |
+ +
05| |
+---------------------------------------------------------------+
06| |
+ STAMP +
07| |
+---------------------------------------------------------------+
08| |
+ DEADLINE +
09| [only if TIMEOUT_DURATION /= DURATION_INFINITE] |
+---------------------------------------------------------------+
10| RESULT_INDEX |
+---------------------------------------------------------------+
11| NEXT_ADDRESS |
+---------------------------------------------------------------+
12| PREV_ADDRESS |
+---------------------------------------------------------------+
\end{lstlisting}
The information of accepted goals is stored in \emph{Goal Data} memory frames (see \cref{Listing}{lst:ros-action-server-goal-data-memory}).
The memory frame fields are explained below:
\begin{itemize}
\item GOAL_STATE\\
The current state of the goal.\\
A goal can have following \emph{active} states:
\begin{itemize}
\item \emph{ACCEPTED}
\item \emph{EXECUTING}
\item \emph{CANCELING}
\end{itemize}
and following \emph{terminal} states:
\begin{itemize}
\item \emph{SUCCEEDED}
\item \emph{ABORTED}
\item \emph{CANCELED}
\end{itemize}
The goals can only transition states in specific ways described in a state machine\cite{ros2-action}.
\item GOAL_ID\\
The \gls{UUID} of the goal.
\item STAMP\\
The time stamp at which the goal was accepted (goal state transitioned to \emph{ACCEPTED}) by the server.
\item DEADLINE\\
The time after which the goal will be removed from memory if the goal is in a terminal state.\\
This field exists only if the \gls{ROS} Action server is configured with a TIMEOUT_DURATION other than infinite.
\item RESULT_INDEX\\
The index/address in the result array/memory that corresponds to this goal.
\end{itemize}
\begin{lstlisting}[basicstyle=\ttfamily\small,float,captionpos=b,caption={\acrshort{ROS} Action Server Result Request Data Memory Frame Format},label={lst:ros-action-server-result-request-data-memory}]
31............24..............16..............8...............0
| | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+---------------------------------------------------------------+
01| GOAL_HANDLE |
+---------------------------------------------------------------+
02| |
+ +
03| |
+ +
04| |
+ REQUEST_ID +
05| |
+ +
06| |
+ +
07| |
+---------------------------------------------------------------+
08| NEXT_ADDRESS |
+---------------------------------------------------------------+
09| PREV_ADDRESS |
+---------------------------------------------------------------+
\end{lstlisting}
Result requests from clients are stored in \emph{Result Request Data} memory frames (see \cref{Listing}{lst:ros-action-server-result-request-data-memory}).
The memory frame fields are explained below:
\begin{itemize}
\item GOAL_HANDLE\\
The goal handle of the requested goal result.
\item REQUEST_ID\\
The \gls{ROS} Service \emph{request_id} to be used for the \gls{ROS} Service response.
\end{itemize}
\section{Protocol Noncompliance}
\label{sec:protocol-noncompliance}
\paragraph{Skip Rest of \acrshort{RTPS} Message on Invalid Inline \gls{QOS}}\mbox{}\\
\label{par:nonconformance-1}
Because the inline \gls{QOS} is not validated in the \gls{RTPS} Handler, and an invalid inline \gls{QOS} invalidates the DATA Submessage (see Section 8.3.7.2.3, \acrshort{DDSI-RTPS} 2.3 \cite{rtps}), we cannot skip the rest of the \gls{RTPS} Message (see Section 8.3.4.1, \acrshort{DDSI-RTPS} 2.3 \cite{rtps}).
\paragraph{Skip Rest of \acrshort{RTPS} Message on Known but Invalid Submessage}\mbox{}\\
\label{par:nonconformance-2}
Although the \gls{RTPS} specification defines the \emph{DataFrag}, \emph{HeartbeatFrag}, and \emph{NackFrag} Submessages as optional (see Section 8.4.14, \acrshort{DDSI-RTPS} 2.3 \cite{rtps}), they are defined as known Submessages (see Section 8.3.4.1 and 8.3.7, \acrshort{DDSI-RTPS} 2.3 \cite{rtps}).
Because this implementation is not implementing the optional fragmentation Submessages, and is thus also not checking their validity, the rest of the \gls{RTPS} message cannot be skipped if a fragmentation Submessage is invalid (see Section 8.3.4.1, \acrshort{DDSI-RTPS} 2.3 \cite{rtps}).
\paragraph{Built-in Endpoints are NOT Regular Endpoints}\mbox{}\\
\label{par:nonconformance-3}
The \gls{RTPS} specification defines built-in \gls{RTPS} endpoints for the discovery module, that act as regular endpoints and their contents can be accessed through the built-in \gls{DDS} endpoints defined by the \gls{DDS} specification (see Section 8.5.2, \acrshort{DDSI-RTPS} 2.3 \cite{rtps}).
For performance and resource usage reasons this implementation is only "simulating" the built-in endpoints and only essential parts of the exchanged meta-traffic information are retained.
Furthermore this retained information cannot be accessed by the user.
\paragraph{ParticipantMessageData may contain General-Purpose Data}\mbox{}\\
\label{par:nonconformance-4}
Although the \hyperref[par:participantmessagedata]{ParticipantMessageData} is for general-purpose data exchange between participants, the \gls{RTPS} specification only defines how it is used to implement the LIVELINESS \gls{QOS}.
For the purpose of interoperability the \gls{RTPS} specification also defines that all implementations should support data fields of at least 128 bytes (see Section 9.6.2.1, \acrshort{DDSI-RTPS} 2.3 \cite{rtps}).
For performance and resource usage reasons this implementation is only using ParticipantMessageData for implementing the LIVELINESS \gls{QOS}, and does not support any other data kinds.
\paragraph{Coherent Sets Not Supported}\mbox{}\\
\label{par:nonconformance-5}
Even though the \gls{DDS} specification defines the PRESENTATION \gls{QOS} with \emph{access scope} GROUP as optional, \emph{coherent access} is not (see Section 2.2.3, DDS 1.4 \cite{dds} and Section 8.7.6, \acrshort{DDSI-RTPS} 2.3 \cite{rtps}).
Due to complexity and implementation time reasons, \emph{coherent access} is not supported.
\paragraph{Partition \gls{QOS} Not Supported}\mbox{}\\
\label{par:nonconformance-6}
According to the \gls{DDS} specification PARTITION \gls{QOS} can be can be regular expressions and include wildcards as defined by the POSIX fnmatch \gls{API} (1003.2-1992 section B.6) (see Section 2.2.3.13, \acrshort{DDS} 1.4 \cite{dds}).
This is a highly sequential demanding requirement unfit for hardware implementation, and was thus decided to not be implemented in light of performance and resource usage.
\chapter{Evaluation}
\label{ch:evaluation}
\section{Introduction}
\label{sec:eval-introduction}
The primary goal of this work is neither to accelerate existing implementations, nor to make a new implementation that is more performant than existing implementations.
Instead the goal is to provide an alternative hardware-only implementation that would allow wider adoption of \gls{ROS}/\gls{DDS} and easier acceleration of code using \gls{ROS}/\gls{DDS} without the need for \gls{CPU} based boards running a (minimal) \gls{OS}.\\
This goal is evaluated with a practical communication between the \gls{ROS} 2 software stack and the implementation of this work, which is detailed in \cref{Section}{sec:eval1}.
Going by the previously stated goal, a performance comparison with existing implementations is moot, since this was never the goal of this work.
A more relevant comparison would be to try to connect \gls{HDL} user-code to a \gls{ROS} network using the current state-of-the-art means on a \gls{FPGA}-only board, and compare it with the implementation of this work in terms of used resources, speedup, power draw, and usability.\\
One way to achieve this would be to use the work described in \cref{Section}{sec:reconfigurable-computing-system-architecture-for-robotic-applications}, but unfortunately the released toolchain only generates the \emph{Standard IP/AXIS Converter} components, and the essential \emph{Manager} and \emph{Communication Interface} components are missing.\\
Another way would be to instantiate a soft-core processor (like MicroBlaze or NIOS II) and run software-based \gls{ROS} on top of it.
For the software-based \gls{ROS} selection, micro-ROS would make the most sense, since this would allow to keep the resources needed by the soft-core processors to a minimum.
Unfortunately, running micro-ROS on top of a soft-core processor could not be achieved in a manageable time frame, and the comparison was thus abandoned.
Either way it would not be a fair comparison, since micro-ROS uses \gls{DDS-XRCE} and the "external" \gls{XRCE} Agent would have to be also taken into account in the comparison.
Despite all that in the end it was decided to follow the trend of related works and make a \gls{SW} vs \gls{HW} performance comparison, which is detailed in \cref{Section}{sec:eval2}.
%Two evaluations are done: The first one is a practical communication between the \gls{ROS} 2 software stack and this work, the second one is a performance comparison between a \gls{ROS} implementation running on an average Computer, a \gls{ROS} implementation running on the \gls{PS} side of the board, and a \gls{ROS} implementation running on the \gls{PL} side of the board.
\section{Evaluation Hardware}
\label{sec:eval-hw}
\begin{figure}
\centering
\includegraphics[width=\textwidth]{graphics/DE10-Nano_Board_Top.jpg}
\caption{Terassic DE10-Nano Board}
\label{fig:de10-nano}
\end{figure}
The evaluation of this work is done using a \emph{Terassic DE10-Nano Board\footnote{Altera Cyclone V SE 5CSEBA6U23I7.}} seen in \cref{Firure}{fig:de10-nano}.
The system as described in \cref{Chapter}{ch:implementation} resides in the \gls{PL} side of the board, whereas the \gls{PS} side of the board is used to forward \gls{UDP} packets to and from the \gls{PL} side.
\subsubsection{\acrshort{PS}-\acrshort{PL} Communication}
Since the \emph{DE10-Nano} Board has no PHY-Ethernet directly connected to the \gls{PL} side, and the fact that a \gls{UDP}/\gls{IP} stack is not part of this work, the \gls{PS} side of the board (the ARM Processor) has to be instantiated and be used for forwarding \gls{UDP} packets to the \gls{PL} side.
The \gls{PS} side is a fully fledged Linux \gls{OS} distribution that intercommunicates with the \gls{PL} side using one of the 3 provided \gls{AXI} buses\footnote{\emph{HPS-to-FPGA Bridge}, \emph{FPGA-to-HPS Bridge}, and \emph{Lightweight HPS-to-FPGA Bridge}.} between the \gls{PS} and \gls{PL} side.
The \gls{PL} implementation is extended with a memory mapped input and output \gls{FIFO}, that allow the \gls{PS} to directly address them via the \emph{lightweight HPS-to-FPGA Bridge}.
A simple C program was written to fetch \gls{UDP} packets from the Linux network stack, and forward them to the to the memory mapped input \gls{FIFO}, and vice versa for the output \gls{FIFO}.
\section{Intercommunication with \acrshort{SW}}
\label{sec:eval1}
\begin{figure}[htp]
\centering
\includegraphics[width=\textwidth]{graphics/system_overview-SYSTEM.pdf}
\caption{Evaluation System Overview}
\label{fig:evaluation-system-overview}
\end{figure}
The main goal for success of this work is to be able to communicate with an existing \gls{ROS} 2 \gls{SW} implementation.\\
As explained in \cref{Section}{subsec:impl-ros-action}, \gls{ROS} actions have the highest abstraction level in the implementation and are built on top of \gls{ROS} services and \gls{ROS} topics, which means that a successful intercommunication between a \gls{ROS} action server and \gls{ROS} action client would in effect test all parts of the implementation.
Since the \gls{ROS} action server has additional complexity in comparison to the \gls{ROS} action client, it makes sense to implement the \gls{ROS} action server in the \gls{FPGA} and the \gls{ROS} action client in the \gls{SW}.
The \emph{Fibonacci} example provided by the \gls{ROS} 2 documentation\cite{ros-action} is used for this purpose, and the \gls{ROS} action server was implemented in \gls{VHDL} and connected to the rest of the implementation described in \cref{Chapter}{ch:implementation}.
The Fibonacci \gls{ROS} action client sends a goal request with the order of the Fibonacci sequence that should be calculated, and the \gls{ROS} action server replies with the final calculated Fibonacci sequence as the goal result, and the partly calculated Fibonacci sequence as the goal feedback.\\
\cref{Figure}{fig:evaluation-system-overview} shows an overview of the test system.
The \gls{ROS} 2 release \emph{Galactic Geochelone} was used for this evaluation, which defaults to the \emph{Eclipse Cyclone DDS} middleware implementation.
First the example is run between a \gls{ROS} action server and client both run in software, and then the \gls{ROS} action server is replaced with the hardware implementation running on the DE10-Nano board.
The hardware implementation successfully communicated with the Cyclone DDS implementation and completed the Fibonacci \gls{ROS} action goal request, thus confirming the correct operation of the implementation of this work.
\subsection{Resource Utilization}
A single \gls{ROS} action server needs to instantiate 3 readers and 6 writers for its operation.\\
\cref{Table}{tab:synthesis-utilization} shows the synthesis results of the Fibonacci \gls{ROS} action server on the DE10-Nano \gls{FPGA}.\\
\texttt{bridge} contains the logic needed for the communication with the \gls{PS} side, along with the input and output \glspl{FIFO}.
\texttt{top} contains the glue-logic needed to interconnect all the system components (mainly \glspl{FIFO}).
\texttt{ros} contains the \gls{ROS} specific logic, like the \emph{ros_time_converter} and \emph{ros_static_discovery_writer} mentioned in \cref{Section}{sec:impl-ros}.
\texttt{ros_action} contains the \gls{ROS} Action, Service, and Topic wrapper logic.
\texttt{Fibonacci_user_logic} contains the actual Fibonacci calculation logic, which is the "user logic" connected to the rest of the system.\\
\cref{Table}{tab:lut-breakdown} breaks-down the \gls{LUT} utilization by type.
\cref{Table}{tab:board-utilization} shows the actual resource utilization of the Fibonacci \gls{ROS} action server on the Terassic DE10-Nano board\footnote{In the DE-10 Nano \gls{FPGA}, the \glspl{LUT} and Registres are contained in special \gls{FPGA} resources called \glspl{ALM}.}.\\
Even though the actual resource utilization of the synthesized and mapped design depends heavily on the target vendor and \gls{FPGA}, by using the detailed \gls{LUT}, Register, Memory and \gls{DSP} utilization stated in \cref{Table}{tab:synthesis-utilization} and \cref{Table}{tab:lut-breakdown} one can get rough estimates across different \glspl{FPGA}.
The memory footprint can also be significantly reduced by selecting different defaults\footnote{e.g. The payload memory of the \gls{ROS} action cancel service is using around 60\% of the \texttt{dds_writer} memory utilization, because the cancel array size is per default set to 100.} and lowering \gls{FIFO} depth sizes.
\begin{table}
\centering
\caption{Synthesis Resource Utilization}
\label{tab:synthesis-utilization}
\begin{tabular}{|p{0.4\textwidth}|>{\raggedleft\arraybackslash}p{0.08\textwidth}|>{\raggedleft\arraybackslash}p{0.11\textwidth}|>{\raggedleft\arraybackslash}p{0.1\textwidth}|>{\raggedleft\arraybackslash}p{0.08\textwidth}|}
\hline
\centering\arraybackslash \textbf{ENTITY} & \centering\arraybackslash \textbf{\acrshortpl{LUT}} & \centering\arraybackslash \textbf{Registers} & \centering\arraybackslash \textbf{Memory Bits} & \centering\arraybackslash \textbf{\acrshort{DSP} Blocks}\\
\hline
{\ttfamily bridge} & 345 & 187 & 1048576 & 0\\
\hline
{\ttfamily top} & 194 & 108 & 564 & 0\\
\hline
{\ttfamily ros} & 176 & 252 & 0 & 4\\
\hline
{\ttfamily ros_action} & 4471 & 3216 & 53966 & 0\\
\hline
{\ttfamily dds_reader} & 5543 & 1724 & 31456 & 0\\
\hline
{\ttfamily dds_writer} & 5217 & 1998 & 482624 & 0\\
\hline
{\ttfamily rtps_reader} & 5546 & 2397 & 85184 & 0\\
\hline
{\ttfamily rtps_writer} & 7837 & 3154 & 169344 & 0\\
\hline
{\ttfamily rtps_discovery_module} & 8750 & 3240 & 41024 & 0\\
\hline
{\ttfamily rtps_handler} & 1677 & 964 & 0 & 0\\
\hline
{\ttfamily rtps_out} & 370 & 185 & 524256 & 0\\
\hline
{\ttfamily Fibonacci_user_logic} & 468 & 185 & 0 & 0\\
\hline
\textbf{TOTAL} & \textbf{40594} & \textbf{17610} & \textbf{2436994} & \textbf{4}\\
\hline
\end{tabular}
\end{table}
\begin{table}
\centering
\caption{\acrshort{LUT} Type Breakdown}
\label{tab:lut-breakdown}
\begin{tabular}{|p{0.2\textwidth}|>{\raggedleft\arraybackslash}p{0.1\textwidth}|}
\hline
\centering\arraybackslash \textbf{\acrshort{LUT} TYPE} & \centering\arraybackslash \textbf{USAGE}\\
\hline
7 Input \acrshortpl{LUT} & 627\\
\hline
6 Input \acrshortpl{LUT} & 8041\\
\hline
5 Input \acrshortpl{LUT} & 9600\\
\hline
4 Input \acrshortpl{LUT} & 9241\\
\hline
$\le$ 3 Input \acrshortpl{LUT} & 13085\\
\hline
\end{tabular}
\end{table}
\begin{table}
\centering
\caption{DE10-Nano Board Resource Utilization}
\label{tab:board-utilization}
\begin{tabular}{|l|c|c|c|}
\hline
\centering\arraybackslash \textbf{BOARD} & \centering\arraybackslash \textbf{\acrshortpl{ALM}} & \centering\arraybackslash \textbf{MEMORY} & \centering\arraybackslash \textbf{\acrshortpl{DSP}}\\
\hline
DE10-Nano & 62.27\% & 43.04\% & 3.57\%\\
\hline
\end{tabular}
\end{table}
\section{Performance Comparison between \acrshort{SW} and \acrshort{HW}}
\label{sec:eval2}
A performance comparison is made between a \gls{ROS} node running on a modern Notebook\footnote{AMD Ryzen 5 5625U, 32 GB DDR4 RAM, RTL8168 1Gb Ethernet.}, a \gls{ROS} node running on the \gls{PS} side of the board, and a \gls{ROS} node running on the \gls{PL} side of the board.\\
The server \gls{ROS} node and the measurements themselves are done in a Workstation\footnote{AMD Ryzen 9 5900X, 64 GB DDR4 RAM, Intel I225-V 2.5Gb Ethernet.} connected to the \gls{DUT}.
Two performance measurements are done:
\begin{itemize}
\item \hyperref[subsec:udp-throughput]{Average \gls{UDP} Throughput}
\item \hyperref[subsec:ros-throughput]{Average \gls{ROS} Message Throughput with Average \gls{RTT}}
\end{itemize}
\subsection{\acrshort{UDP} Throughput}
\label{subsec:udp-throughput}
In the first measurement, the \gls{PL} implementation is just reading the \gls{UDP} packets from the input \gls{FIFO}, swapping the source and destination address/port, and writing it back to the output \gls{FIFO}.
This can be used to measure the performance/throughput of the \gls{PS}-\gls{PL} \gls{UDP} forwarding, which is measurably the current bottleneck of the intercommunication\footnote{A much better throughput could be achieved by using the high performance \gls{AXI} bridges together with a \gls{DMA} controller.}.\\
The measurement is done twice, once with \gls{UDP} packets with 56 Bytes of payload, and once with \gls{UDP} packets with 100 Bytes of payload.
This is done, because during the next performance measurement, this implementation and the Cyclone DDS implementation send out different sized \gls{UDP} payloads\footnote{56 Bytes for this implementation and 100 Bytes for the Cyclone DDS implementation.} due to Cyclone DDS transmitting some additional "redundant" information.\\
A C++ implementation that mirrors the \gls{PL} behaviour in \gls{SW} is also written.
The average \gls{UDP} throughput measurements can be found in \cref{Table}{tab:udp-throughput}.
\begin{table}[htp]
\centering
\caption{Average \acrshort{UDP} Packet Throughput Results}
\label{tab:udp-throughput}
\begin{tabular}{|l|>{\raggedleft\arraybackslash}p{0.15\textwidth}|>{\raggedleft\arraybackslash}p{0.2\textwidth}|}
\hline
\textbf{Description} & \centering\arraybackslash \textbf{\acrshort{UDP} Payload Size (Bytes)} & \centering\arraybackslash \textbf{Throughput (Pkts/s)}\\
\hline
\multirow{2}{*}{Workstation-Notebook} & 100 & 158953\\
\cline{2-3}
& 56 & 159974\\
\hline
\multirow{2}{*}{Workstation-\acrshort{PS}} & 100 & 30212\\
\cline{2-3}
& 56 & 30568\\
\hline
\multirow{2}{*}{Workstation-\acrshort{PL}} & 100 & 16052\\
\cline{2-3}
& 56 & 19260\\
\hline
\end{tabular}
\end{table}
The \emph{Workstation-Notebook} measurements act as a sanity check, and should be substantially higher than the other measurements.
If that would not be the case, it would suggest a bottleneck in the Workstation, and the measurements would be void.\\
The \emph{Workstation-\gls{PS}} measurements show the practical limit of the Linux \gls{UDP}/\gls{IP} stack running on the \gls{PS} side. This is also the theoretical upper limit of the \emph{Workstation-\gls{FPGA}} measurements, since the \gls{FPGA} is relying on the Linux \gls{UDP}/\gls{IP} stack.\\
Since the \emph{Workstation-\gls{PL}} measurements are significantly lower (53\%-63\% of the \emph{Workstation-\gls{PS}} throughput), it suggests that there is a bottleneck in the \gls{PS}-\gls{PL} communication (which is to be expected).
The \gls{PS}-\gls{PL} bridge has a practical bi-directional throughput of around 1.6 MB/s\footnote{The \gls{UDP} Payloads are transferred to/from the \gls{PL} with a 16 Byte header.}.
\subsection{\acrshort{ROS} Message Throughput and \acrshort{RTT}}
\label{subsec:ros-throughput}
For the second measurement a simple \gls{ROS} client/server loopback was implemented, where the server publishes messages with an \gls{ID} on Topic \emph{Loopback_1} and the client mirrors the messages by sending them back through Topic \emph{Loopback_2}.
The server can then use the \gls{ID} of the mirrored message to measure the \gls{RTT} of the message.\\
This can be used to compare the overhead incurred by each \gls{ROS} implementation.
The first performance measurement represents the maximum practical achievable throughput and can be used as base for the overhead estimation.
\cref{Table}{tab:ros-throughput} show the measured average \gls{ROS} message throughput and \gls{RTT}.
\begin{table}[htp]
\centering
\caption{Average \gls{ROS} Message Throughput and \gls{RTT}}
\label{tab:ros-throughput}
\begin{tabular}{|l|>{\raggedleft\arraybackslash}p{0.2\textwidth}|>{\raggedleft\arraybackslash}p{0.2\textwidth}|}
\hline
\textbf{Description} & \centering\arraybackslash \textbf{Throughput (Pkts/s)} & \centering\arraybackslash \textbf{\acrshort{RTT} (ns)}\\
\hline
Workstation-Notebook & 56215 & 174301\\
\hline
Workstation-\acrshort{PS} & 2547 & 3926030\\
\hline
Workstation-\acrshort{PL} & 10981 & 415491\\
\hline
\end{tabular}
\end{table}
The \emph{Workstation-\gls{PL}} measurement achieves 68\% of the maximum throughput, whereas the \emph{Workstation-Notebook} and \emph{Workstation-\gls{PS}} achieve 35\% and 8\% of their maximum throughput, respectively.
This suggests a substantially lower overhead for the implementation of this work.\\
Additionally, despite the \emph{Workstation-\gls{PL}} measurement having only 20\% of the throughput of the \emph{Workstation-Notebook} measurement, the \emph{Workstation-Notebook} measurement has only a 42\% better \gls{RTT}.\\
The relevant comparison with the \emph{Workstation-\gls{PS}} measurement shows a 331\% improved throughput and a 89\% reduced \gls{RTT} for the \emph{Workstation-\gls{PL}} measurement.
The performance of the \gls{PL} implementation is directly correlated to the operating frequency, which for this measurements is 50 MHz.
Since the \gls{PL} implementation has an input/output width of 32-bits, and the \texttt{rtps_handler} could consume one input word each clock cycle, the \gls{PL} implementation has a theoretical throughput of 200 MB/s.
Since the implementation contains \glspl{FSM} with states that do not "consume" input words\footnote{e.g. states waiting on memory access, or states that are split into sub-states for complex operations.} this theoretical throughput is never practically achieved, but can be considered an upper limit.
Considering that in this measurement, contrary to the first performance measurement, extra packets needed by the protocols are not taken into account in the throughput measurement, it seems that the \gls{PL} implementation is still hitting the \gls{PS}-\gls{PL} bridge bottleneck with 30\% protocol overhead.
This is further affirmed by the average input and output \gls{FIFO} utilization of the \gls{PL}, which is 0.00136205\% and 0.0834316\%, respectively\footnote{Both \glspl{FIFO} are 65536 Bytes in size.}.
\chapter{Conclusion \& Future Work}
\label{ch:conclusion}
The successful intercommunication with an existing \gls{SW} implementation described in \cref{Section}{sec:eval1} confirms the correct operation of the implementation.\\
With that the goal of this work, which is to provide a \gls{HW}-only implementation of the \gls{RTPS} protocol, \gls{DDS} protocol, and \gls{ROS} framework, is reached.\\
In addition to that the comparable higher performance measured in \cref{Section}{sec:eval2} shows that this work may also provide an alternative for programmable \glspl{SOC} with a net performance improvement.
The source code of this work is available under TODO.
Future work will entail further improving the performance, implementing left-out or optional parts of the protocol specifications, and testing intercommunication with implementations other than Cyclone DDS.
%TODO:
%\begin{itemize}
% \item \sout{ROS Action Client Timing Diagrams}
% \item \sout{ROS Action Server Timing Diagrams}
% \item \sout{Document design decision of ROS Action Server interface}
% \item \sout{ros_action_server Entity Documentation}
% \item \sout{Finish ROS Action MSc Section}
% \item \sout{Reduce \texttt{sequence_id} validity length in Timing Diagrams to bare minimum}
% \item \sout{Check feasibility of moving average on FIFO utilization}
% \item \sout{DO ping tests with RTT measurements}
% \item \sout{Explain the start/done, valid/ready schema in one point, and reference there}
% \item \sout{Note how we do not implement Listeners, Conditions, and WaitSets of DDS}
% \item \sout{Write Evaluation Chapter}
% \item \sout{Write Conclusion Chapter}
% \item \sout{Write Introduction}
% \item \sout{Write Abstract}
% \item \sout{Add missing Diagrams}
% \item \sout{Handle all TODOs}
% \item \sout{Add abbreviations for SW, HW, CPU, LUT, DSP, ID, ALM}
% \item \sout{Recheck use of GLS abbreviations}
% \item \sout{Make sure all footnotes end with '.'}
% \item \sout{Make sure all 'a' before RTPS are converted to 'an'. (Really common mistake in this thesis)}
% \item \sout{Fix Title Size}
% \item \sout{Put commands of Timing Diagrams captions inside texttt}
% \item \sout{Describe all return codes and opcodes (where applicable) in Timing Diagrams}
% \item \sout{Use thesis when refering to this document, else work}
% \item \sout{Make sure all mentions of HistoryCache and CacheChange are universaly prefixed with RTPS to reduce ambiguity}
% \item \sout{Use \verb|\acrfull| on the respective "first" explanation site to ensure full word even if previously mentioned.}
% \item Use \verb|\emph{}| only on terms explained in the respective section and other "new" terms.
% \item \sout{Move stuff to Appendix}
%\end{itemize}
%REF: gls replace Regex
% FIND: (.?(?<!glspl{|gls{|acrshort{|acrshortpl{|acrfull{))(?<!\w)(RTPS)
% REPLACE: \1\gls{\2}
%REF: a/an replace Regex
% FIND: (a)(\s\\\w*{RTPS})
% REPLACE: \1n\2
%NOTE: The configuration setting of ROS entities (like TIMEOUT_DURATION) are not documented anywhere in this paper.
\backmatter
\printbibliography[title={References}]
\chapter{Appendix}
\label{ch:appendix}
\section{Listings}
\label{sec:lst}
\subsection{\acrshort{RTPS} Handler}
\label{subsec:lst-rtps-handler}
\begin{lstlisting}[basicstyle=\ttfamily\small,float,captionpos=b,caption={Output Format of \acrshort{RTPS} Handler.},label={lst:rtps-handler-out}]
31............24..............16..............8...............0
| | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+---------------+---------------+-------------------------------+
01| OPCODE | FLAGS | SRC_UDP_PORT |
+---------------+---------------+-------------------------------+
02| SRC_IPv4_ADDR |
+---------------------------------------------------------------+
03| |
+ +
04| SRC_GUIDPREFIX |
+ +
05| |
+---------------------------------------------------------------+
06| SRC_ENTITYID |
+---------------------------------------------------------------+
07| DEST_ENTITYID [only for Discovery Module] |
+---------------------------------------------------------------+
08| |
+ Sequence Number [only for DATA Submessage] +
09| |
+---------------------------------------------------------------+
10| |
+ Timestamp +
11| [only for DATA Submessage and User Endpoints] |
+---------------------------------------------------------------+
12| |
~ PAYLOAD (SUBMESSAGE CONTENT) ~
**| |
+---------------------------------------------------------------+
\end{lstlisting}
\begin{lstlisting}[basicstyle=\ttfamily\small,float,captionpos=b,caption={HEARTBEAT Payload Format of \acrshort{RTPS} Handler Output.},label={lst:rtps-handler-out-heartbeat}]
31............24..............16..............8...............0
| | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+---------------------------------------------------------------+
01| |
+ FirstSN +
02| |
+---------------------------------------------------------------+
03| |
+ LastSN +
04| |
+---------------------------------------------------------------+
05| Count |
+---------------------------------------------------------------+
\end{lstlisting}
\begin{lstlisting}[basicstyle=\ttfamily\small,float,captionpos=b,caption={ACKNACK Payload Format of \acrshort{RTPS} Handler Output.},label={lst:rtps-handler-out-acknack}]
31............24..............16..............8...............0
| | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+---------------------------------------------------------------+
01| |
+ ReaderSNState.BASE +
02| |
+---------------------------------------------------------------+
03| ReaderSNState.NumBits |
+---------------------------------------------------------------+
04| |
~ [ReaderSNState.Bitmap] x 0-8 ~
**| |
+---------------------------------------------------------------+
**| Count |
+---------------------------------------------------------------+
\end{lstlisting}
\begin{lstlisting}[basicstyle=\ttfamily\small,float,captionpos=b,caption={GAP Payload Format of \acrshort{RTPS} Handler Output.},label={lst:rtps-handler-out-gap}]
31............24..............16..............8...............0
| | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+---------------------------------------------------------------+
01| |
+ GapStart +
02| |
+---------------------------------------------------------------+
03| |
+ GapList.BASE +
04| |
+---------------------------------------------------------------+
05| GapList.NumBits |
+---------------------------------------------------------------+
06| |
~ [GapList.Bitmap] x 0-8 ~
**| |
+---------------------------------------------------------------+
**| UNUSED |
+---------------------------------------------------------------+
\end{lstlisting}
\subsection{\acrshort{RTPS} Discovery Module}
\label{subsec:lst-rtps-discovery-module}
\begin{lstlisting}[basicstyle=\ttfamily\small,float,captionpos=b,caption={Endpoint Match Frame},label={lst:endpoint-match-frame}]
31............24..............16..............8...............0
| | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+---------------------------------------------------------------+
00| OPCODE (=0x55000000) |
+---------------------------------------------------------------+
01| |
+ +
02| GUIDPREFIX |
+ +
03| |
+---------------------------------------------------------------+
04| ENTITYID |
+---------------------------------------------------------------+
05| IPv4_ADDRESS |
+-------------------------------+-------------------------------+
06| UDP_PORT | READER_FLAGS |
+-------------------------------+-------------------------------+
07| |
+ LIFESPAN_DURATION +
08| [only for Reader Endpoints] |
+-------------------------------+-------------------------------+
READER_FLAGS
------------
15............8...............0
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-------------------------+-+-+-+
| UNUSED |B|H|Q|
+-------------------------+-+-+-+
Q...Reader expects in-line QoS
H...Reader expects Historical Data
B...Reader has RELIABILITY BEST_EFFORT
\end{lstlisting}
\begin{lstlisting}[basicstyle=\ttfamily\small,float,captionpos=b,caption={Endpoint Unmatch Frame},label={lst:endpoint-unmatch-frame}]
31............24..............16..............8...............0
| | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+---------------------------------------------------------------+
00| OPCODE (=0x55000001) |
+---------------------------------------------------------------+
01| |
+ +
02| GUIDPREFIX |
+ +
03| |
+---------------------------------------------------------------+
04| ENTITYID |
+---------------------------------------------------------------+
\end{lstlisting}
\begin{lstlisting}[basicstyle=\ttfamily\small,float,captionpos=b,caption={Participant Unmatch Frame},label={lst:participant-unmatch-frame}]
31............24..............16..............8...............0
| | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+---------------------------------------------------------------+
00| OPCODE (=0x55000002) |
+---------------------------------------------------------------+
01| |
+ +
02| GUIDPREFIX |
+ +
03| |
+---------------------------------------------------------------+
\end{lstlisting}
\begin{lstlisting}[basicstyle=\ttfamily\small,float,captionpos=b,caption={Endpoint Liveliness Update},label={lst:endpoint-liveliness-update}]
31............24..............16..............8...............0
| | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+---------------------------------------------------------------+
00| OPCODE (=55000003) |
+---------------------------------------------------------------+
01| |
+ +
02| GUIDPREFIX |
+ +
03| |
+---------------------------------------------------------------+
\end{lstlisting}
\subsection{\acrshort{RTPS} Reader}
\label{lst:rtps-reader}
\begin{lstlisting}[basicstyle=\ttfamily\small,float,captionpos=b,caption={ADD_CACHE_CHANGE Data Format},label={lst:add-cache-change-format}]
31............24..............16..............8...............0
| | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+---------------------------------------------------------------+
00| STATUS_INFO |
+---------------------------------------------------------------+
01| |
+ TIMESTAMP +
02| |
+---------------------------------------------------------------+
03| |
+ LIFESPAN_DEADLINE +
04| |
+---------------------------------------------------------------+
05| |
+ +
06| |
+ KEY_HASH [only if K=1] +
07| |
+ +
08| |
+---------------------------------------------------------------+
09| WRITER_ID |
+---------------------------------------------------------------+
10| |
~ PAYLOAD [only if P=1 or P=K=0] ~
**| |
+---------------------------------------------------------------+
STATUS INFO
-----------
31............24..............16..............8...............0
| | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-------------------------------------------------+-+-+-+
| |P| |K| UNUSED |F|U|D|
+-+-+-+-+-------------------------------------------------+-+-+-+
P...Sample has associated DATA Payload
K...Key Hash available
F...FilteredFlag (1:1 PID_STATUS_INFO Mapping)
U...UnregisteredFlag (1:1 PID_STATUS_INFO Mapping)
D...DisposedFlag (1:1 PID_STATUS_INFO Mapping)
NOTE: If P=0 and K=0, the Payload contains the Serialized Key
\end{lstlisting}
\begin{lstlisting}[basicstyle=\ttfamily\small,float,captionpos=b,caption={REMOVE_WRITER Data Format},label={lst:remove-writer-format}]
31............24..............16..............8...............0
| | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+---------------------------------------------------------------+
01| WRITER_ID |
+---------------------------------------------------------------+
\end{lstlisting}
\subsection{\acrshort{RTPS} Out}
\label{lst:rtps-out}
\begin{lstlisting}[basicstyle=\ttfamily\small,float,captionpos=b,caption={Input Format of \acrshort{RTPS} Out.},label={lst:rtps-out-in}]
31............24..............16..............8...............0
| | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+---------------------------------------------------------------+
01| SRC_IPv4_ADDR |
+---------------------------------------------------------------+
02| DEST_IPv4_ADDR |
+-------------------------------+-------------------------------+
03| SRC_UDP_PORT | DEST_UDP_PORT |
+-------------------------------+-------------------------------+
04| |
~ RTPS_PACKET ~
**| |
+---------------------------------------------------------------+
\end{lstlisting}
\subsection{\acrshort{DDS} Reader}
\label{lst:dds-reader}
\begin{lstlisting}[basicstyle=\ttfamily\small,float,captionpos=b,caption={GET_SAMPLE_REJECTED_STATUS Data Format},label={lst:get-sample-rejected-status-format}]
31............24..............16..............8...............0
| | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+---------------------------------------------------------------+
01| TOTAL_COUNT |
+---------------------------------------------------------------+
02| TOTAL_COUNT_CHANGE |
+---------------------------------------------------------------+
03| LAST_REASON |
+---------------------------------------------------------------+
04| |
+ +
05| |
+ LAST_INSTANCE_HANDLE +
06| |
+ +
07| |
+---------------------------------------------------------------+
\end{lstlisting}
\begin{lstlisting}[basicstyle=\ttfamily\small,float,captionpos=b,caption={GET_REQUESTED_DEADLINE_MISSED Data Format},label={lst:get-requested-deadline-missed-status-format}]
31............24..............16..............8...............0
| | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+---------------------------------------------------------------+
01| TOTAL_COUNT |
+---------------------------------------------------------------+
02| TOTAL_COUNT_CHANGE |
+---------------------------------------------------------------+
03| |
+ +
04| |
+ LAST_INSTANCE_HANDLE +
05| |
+ +
06| |
+---------------------------------------------------------------+
\end{lstlisting}
\subsection{\acrshort{DDS} Writer}
\label{lst:dds-writer}
\begin{lstlisting}[basicstyle=\ttfamily\small,float,captionpos=b,caption={GET_OFFERED_DEADLINE_MISSED_STATUS Data Format},label={lst:get-offered-deadline-missed-status-format}]
31............24..............16..............8...............0
| | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+---------------------------------------------------------------+
01| TOTAL_COUNT |
+---------------------------------------------------------------+
02| TOTAL_COUNT_CHANGE |
+---------------------------------------------------------------+
03| |
+ +
04| |
+ LAST_INSTANCE_HANDLE +
05| |
+ +
06| |
+---------------------------------------------------------------+
\end{lstlisting}
\begin{lstlisting}[basicstyle=\ttfamily\small,float,captionpos=b,caption={GET_LIVELINESS_LOST_STATUS Data Format},label={lst:get-liveliness-lost-status-format}]
31............24..............16..............8...............0
| | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+---------------------------------------------------------------+
01| TOTAL_COUNT |
+---------------------------------------------------------------+
02| TOTAL_COUNT_CHANGE |
+---------------------------------------------------------------+
\end{lstlisting}
\section{Timing Diagrams}
\label{sec:tim}
\subsection{\acrshort{RTPS} Reader}
\label{tim:rtps-reader}
\begin{timingdiag}
\centering
\begin{tikztimingtable}
clk & [L]13{CC}\\
\color{Red} start & [L]{LL}2{HH}10{LL}\\
\color{Red} opcode & {UU}1{DDDD}{\tiny ADD}10{UU}\\
\color{Blue}ack & [L]2{LL}{HH}10{LL}\\
\color{Red} valid_in & [L]3{LL}2{HH}{LL}2{HH};[dotted]HH;{HH}3{LL}\\
\color{Blue}ready_in & [L]4{LL}{HH}{LL}2{HH};[dotted]HH;{HH}3{LL}\\
\color{Red} data_in & 3{UU}2{DD}{}{UU}2{DD{}};[dotted]DD{};{DD}3{UU}\\
\color{Red} last_word_in & [L]8{LL};[dotted]LL;{HH}3{LL}\\
\color{Blue}done & [L]11{LL}{HH}{LL}\\
\color{Blue}ret & 11{UU}1{DD}{OK}{UU}\\
\begin{extracode}
\tableheader{Signal}{Relation}
\fulltablegrid[black!25,ystep=1,xstep=2]
\tablerules
\end{extracode}
\end{tikztimingtable}
\caption{\texttt{ADD_CACHE_CHANGE} \acrshort{RTPS} HistoryCache Operation}
\label{tim:add-cache-change}
\end{timingdiag}
\begin{timingdiag}
\centering
\begin{tikztimingtable}
clk & [L]6{CC}\\
\color{Red} start & [L]{LL}2{HH}3{LL}\\
\color{Red} opcode & {UU}1{DDDD}{\tiny REMOVE}3{UU}\\
\color{Blue}ack & [L]2{LL}{HH}3{LL}\\
\color{Red} valid_in & [L]6{LL}\\
\color{Blue}ready_in & [L]6{LL}\\
\color{Red} data_in & {UU}2{DD}{}3{UU}\\
\color{Red} last_word_in & [L]6{LL}\\
\color{Blue}done & [L]4{LL}{HH}{LL}\\
\color{Blue}ret & 4{UU}1{DD}{OK}{UU}\\
\begin{extracode}
\tableheader{Signal}{Relation}
\fulltablegrid[black!25,ystep=1,xstep=2]
\tablerules
\end{extracode}
\end{tikztimingtable}
\caption{\texttt{REMOVE_WRITER} \acrshort{RTPS} HistoryCache Operation}
\label{tim:remove-writer}
\end{timingdiag}
\subsection{\acrshort{RTPS} Writer}
\label{tim:rtps-writer}
\begin{timingdiag}
\centering
\begin{tikztimingtable}
clk & [L]17{CC}\\
\color{Red} start & [L]{LL}{HH}3{LL}2{HH}10{LL}\\
\color{Red} opcode & {UU}1{DD}{\tiny GET}3{UU}2{DD}{\tiny GET}10{UU}\\
\color{Red} seq_nr & {UU}{DD}3{UU}{4D}10{UU}\\
\color{Blue}ack & [L]1{LL}{HH}4{LL}{HH}10{LL}\\
\color{Blue}done & [L]3{LL}{HH}4{LL}{HH}8{LL}\\
\color{Blue}ret & 3{UU}1{DD}{OK}4{UU}1{DD}{OK}8{UU}\\
\color{Blue}cc_seq_nr & 3{UU}{8D}{UU}{18D}\\
\color{Blue}cc_instance_handle & 3{UU}{8D}{UU}{18D}\\
\color{Blue}cc_kind & 3{UU}{8D}{UU}{18D}\\
\color{Blue}cc_source_timestamp & 3{UU}{8D}{UU}{18D}\\
\color{Red} get_data & [L]8{LL}{HH}8{LL}\\
\color{Blue}valid_out & [L]9{LL}2{HH}{LL}2{HH};[dotted]HH;{HH}{LL}\\
\color{Red} ready_out & [L]10{LL}{HH}{LL}2{HH};[dotted]HH;{HH}{LL}\\
\color{Blue}data_out & 9{UU}2{DD}{}{UU}2{DD{}};[dotted]DD{};{DD}{UU}\\
\color{Blue}last_word_out & [L]14{LL};[dotted]LL;{HH}{LL}\\
\begin{extracode}
\tableheader{Signal}{Relation}
\fulltablegrid[black!25,ystep=1,xstep=2]
\tablerules
\end{extracode}
\end{tikztimingtable}
\caption{\texttt{GET_CACHE_CHANGE} \acrshort{RTPS} HistoryCache Operation}
\label{tim:get-cache-change}
\end{timingdiag}
\begin{timingdiag}
\centering
\begin{tikztimingtable}
clk & [L]6{CC}\\
\color{Red} start & [L]{LL}2{HH}3{LL}\\
\color{Red} opcode & {UU}{DDDD}3{UU}\\
\color{Red} seq_nr & {UU}{DDDD}3{UU}\\
\color{Blue}ack & [L]2{LL}{HH}3{LL}\\
\color{Blue}done & [L]4{LL}{HH}{LL}\\
\color{Blue}ret & 4{UU}1{DD}{OK}{UU}\\
\color{Blue}cc_seq_nr & 6{UU}\\
\color{Blue}cc_instance_handle & 6{UU}\\
\color{Blue}cc_kind & 6{UU}\\
\color{Blue}cc_source_timestamp & 6{UU}\\
\color{Red} get_data & [L]6{LL}\\
\color{Blue}valid_out & [L]6{LL}\\
\color{Red} ready_out & [L]6{LL}\\
\color{Blue}data_out & 6{UU}\\
\color{Blue}last_word_out & [L]6{LL}\\
\begin{extracode}
\tableheader{Signal}{Relation}
\fulltablegrid[black!25,ystep=1,xstep=2]
\tablerules
\end{extracode}
\end{tikztimingtable}
\caption{\texttt{ACK_CACHE_CHANGE}, \texttt{NACK_CACHE_CHANGE}, and \texttt{REMOVE_CACHE_CHANGE} \acrshort{RTPS} HistoryCache Operations}
\label{tim:nack-cache-change}
\end{timingdiag}
\begin{timingdiag}
\centering
\begin{tikztimingtable}
clk & [L]10{CC}\\
\color{Red} start & [L]{LL}{HH}3{LL}2{HH}3{LL}\\
\color{Red} opcode & {UU}1{DD}{\tiny GET}3{UU}2{DD}{\tiny GET}3{UU}\\
\color{Red} seq_nr & 10{UU}\\
\color{Blue}ack & [L]1{LL}{HH}4{LL}{HH}3{LL}\\
\color{Blue}done & [L]3{LL}{HH}4{LL}{HH}1{LL}\\
\color{Blue}ret & 3{UU}1{DD}{OK}4{UU}1{DD}{OK}1{UU}\\
\color{Blue}cc_seq_nr & 3{UU}{8D}{UU}{4D}\\
\color{Blue}cc_instance_handle & 10{UU}\\
\color{Blue}cc_kind & 10{UU}\\
\color{Blue}cc_source_timestamp & 10{UU}\\
\color{Red} get_data & [L]10{LL}\\
\color{Blue}valid_out & [L]10{LL}\\
\color{Red} ready_out & [L]10{LL}\\
\color{Blue}data_out & 10{UU}\\
\color{Blue}last_word_out & [L]10{LL}\\
\begin{extracode}
\tableheader{Signal}{Relation}
\fulltablegrid[black!25,ystep=1,xstep=2]
\tablerules
\end{extracode}
\end{tikztimingtable}
\caption{\texttt{GET_MIN_SN} and \texttt{GET_MAX_SN} \acrshort{RTPS} HistoryCache Operations}
\label{tim:get-min-sn}
\end{timingdiag}
\subsection{\acrshort{DDS} Reader}
\label{tim:dds-reader}
\begin{timingdiag}
\centering
\begin{tikztimingtable}
clk & [L]23{CC}\\
\color{Red} start & [L]{LL}2{HH}20{LL}\\
\color{Red} opcode & {UU}{DDDD}20{UU}\\
\color{Red} sample_state & {UU}{DDDD}20{UU}\\
\color{Red} view_state & {UU}{DDDD}20{UU}\\
\color{Red} instance_state & {UU}{DDDD}20{UU}\\
\color{Red} max_samples & {UU}{DDDD}20{UU}\\
\color{Red} instance_handle & 23{UU}\\
\color{Blue}ack & [L]2{LL}{HH}20{LL}\\
\color{Blue}done & [L]4{LL}{HH}18{LL}\\
\color{Blue}return_code & 4{UU}1{DD}{OK}18{UU}\\
\color{Blue}sample_info_valid & [L]6{LL}2{HH}{LL}{HH}8{LL};[dotted]LL;{HH}3{LL}\\
\color{Blue}sample_info & 6{UU}2{DD}{}{UU}{DD}8{UU};[dotted]DD{};{DD}3{UU}\\
\color{Red} sample_info_ack & [L]7{LL}{HH}{LL}{HH}8{LL};[dotted]LL;{HH}3{LL}\\
\color{Red} get_data & [L]9{LL}{HH}8{LL};[dotted]LL;4{LL}\\
\color{Blue}valid_out & [L]10{LL}2{HH}{LL}2{HH};[dotted]HH;{HH}1{LL};[dotted]LL;4{LL}\\
\color{Red} ready_out & [L]11{LL}{HH}{LL}2{HH};[dotted]HH;{HH}1{LL};[dotted]LL;4{LL}\\
\color{Blue}data_out & 10{UU}2{DD}{}{UU}2{DD{}};[dotted]DD{};{DD}1{UU};[dotted]DD{};4{UU}\\
\color{Blue}last_word_out & [L]15{LL};[dotted]LL;{HH}1{LL};[dotted]LL;4{LL}\\
\color{Blue}eoc & [L]18{LL};[dotted]LL;2{LL}{HH}{LL}\\
\begin{extracode}
\tableheader{Signal}{Relation}
\fulltablegrid[black!25,ystep=1,xstep=2]
\tablerules
\end{extracode}
\end{tikztimingtable}
\caption{\texttt{READ} and \texttt{TAKE} \acrshort{DDS} Operations}
\label{tim:read}
\end{timingdiag}
\begin{timingdiag}
\centering
\begin{tikztimingtable}
clk & [L]23{CC}\\
\color{Red} start & [L]{LL}2{HH}14{LL}{HH}5{LL}\\
\color{Red} opcode & {UU}{DDDD}14{UU}{DD}5{UU}\\
\color{Red} sample_state & 23{UU}\\
\color{Red} view_state & 23{UU}\\
\color{Red} instance_state & 23{UU}\\
\color{Red} max_samples & 23{UU}\\
\color{Red} instance_handle & 23{UU}\\
\color{Blue}ack & [L]2{LL}{HH}14{LL}{HH}5{LL}\\
\color{Blue}done & [L]4{LL}{HH}13{LL}{HH}4{LL}\\
\color{Blue}return_code & 4{UU}1{DD}{OK}13{UU}1{DD}{OK}4{UU}\\
\color{Blue}sample_info_valid & [L]6{LL}2{HH}12{LL}{HH}2{LL}\\
\color{Blue}sample_info & 6{UU}2{DD}12{UU}{DD}2{UU}\\
\color{Red} sample_info_ack & [L]7{LL}{HH}12{LL}{HH}2{LL}\\
\color{Red} get_data & [L]7{LL}{HH}8{LL}7{LL}\\
\color{Blue}valid_out & [L]8{LL}2{HH}{LL}2{HH};[dotted]HH;{HH}1{LL}7{LL}\\
\color{Red} ready_out & [L]9{LL}{HH}{LL}2{HH};[dotted]HH;{HH}1{LL}7{LL}\\
\color{Blue}data_out & 8{UU}2{DD}{}{UU}2{DD{}};[dotted]DD{};{DD}1{UU}7{UU}\\
\color{Blue}last_word_out & [L]13{LL};[dotted]LL;{HH}1{LL}7{LL}\\
\color{Blue}eoc & [L]15{LL}{HH}5{LL}{HH}{LL}\\
\begin{extracode}
\tableheader{Signal}{Relation}
\fulltablegrid[black!25,ystep=1,xstep=2]
\tablerules
\end{extracode}
\end{tikztimingtable}
\caption{\texttt{READ_NEXT_SAMPLE} and \texttt{TAKE_NEXT_SAMPLE} \acrshort{DDS} Operations}
\label{tim:read-next-sample}
\end{timingdiag}
\begin{timingdiag}
\centering
\begin{tikztimingtable}
clk & [L]23{CC}\\
\color{Red} start & [L]{LL}2{HH}20{LL}\\
\color{Red} opcode & {UU}{DDDD}20{UU}\\
\color{Red} sample_state & {UU}{DDDD}20{UU}\\
\color{Red} view_state & {UU}{DDDD}20{UU}\\
\color{Red} instance_state & {UU}{DDDD}20{UU}\\
\color{Red} max_samples & {UU}{DDDD}20{UU}\\
\color{Red} instance_handle & {UU}{DDDD}20{UU}\\
\color{Blue}ack & [L]2{LL}{HH}20{LL}\\
\color{Blue}done & [L]4{LL}{HH}18{LL}\\
\color{Blue}return_code & 4{UU}1{DD}{OK}18{UU}\\
\color{Blue}sample_info_valid & [L]6{LL}2{HH}{LL}{HH}8{LL};[dotted]LL;{HH}3{LL}\\
\color{Blue}sample_info & 6{UU}2{DD}{}{UU}{DD}8{UU};[dotted]DD{};{DD}3{UU}\\
\color{Red} sample_info_ack & [L]7{LL}{HH}{LL}{HH}8{LL};[dotted]LL;{HH}3{LL}\\
\color{Red} get_data & [L]9{LL}{HH}8{LL};[dotted]LL;4{LL}\\
\color{Blue}valid_out & [L]10{LL}2{HH}{LL}2{HH};[dotted]HH;{HH}1{LL};[dotted]LL;4{LL}\\
\color{Red} ready_out & [L]11{LL}{HH}{LL}2{HH};[dotted]HH;{HH}1{LL};[dotted]LL;4{LL}\\
\color{Blue}data_out & 10{UU}2{DD}{}{UU}2{DD{}};[dotted]DD{};{DD}1{UU};[dotted]DD{};4{UU}\\
\color{Blue}last_word_out & [L]15{LL};[dotted]LL;{HH}1{LL};[dotted]LL;4{LL}\\
\color{Blue}eoc & [L]18{LL};[dotted]LL;2{LL}{HH}{LL}\\
\begin{extracode}
\tableheader{Signal}{Relation}
\fulltablegrid[black!25,ystep=1,xstep=2]
\tablerules
\end{extracode}
\end{tikztimingtable}
\caption{\texttt{READ_INSTANCE}, \texttt{TAKE_INSTANCE}, \texttt{READ_NEXT_INSTANCE}, and \texttt{TAKE_NEXT_INSTANCE} \acrshort{DDS} Operations}
\label{tim:read-instance}
\end{timingdiag}
\begin{timingdiag}
\centering
\begin{tikztimingtable}
clk & [L]13{CC}\\
\color{Red} start & [L]{LL}2{HH}10{LL}\\
\color{Red} opcode & {UU}1{DDDD}{\tiny GET}10{UU}\\
\color{Red} sample_state & 13{UU}\\
\color{Red} view_state & 13{UU}\\
\color{Red} instance_state & 13{UU}\\
\color{Red} max_samples & 13{UU}\\
\color{Red} instance_handle & 13{UU}\\
\color{Blue}ack & [L]2{LL}{HH}10{LL}\\
\color{Blue}done & [L]4{LL}{HH}8{LL}\\
\color{Blue}return_code & 4{UU}1{DD}{OK}8{UU}\\
\color{Blue}sample_info_valid & [L]13{LL}\\
\color{Blue}sample_info & 13{UU}\\
\color{Red} sample_info_ack & [L]13{LL}\\
\color{Red} get_data & [L]13{LL}\\
\color{Blue}valid_out & [L]5{LL}2{HH}{LL}2{HH};[dotted]HH;{HH}1{LL}\\
\color{Red} ready_out & [L]6{LL}{HH}{LL}2{HH};[dotted]HH;{HH}1{LL}\\
\color{Blue}data_out & 5{UU}2{DD}{}{UU}2{DD{}};[dotted]DD{};{DD}1{UU}\\
\color{Blue}last_word_out & [L]10{LL};[dotted]LL;{HH}1{LL}\\
\color{Blue}eoc & [L]13{LL}\\
\begin{extracode}
\tableheader{Signal}{Relation}
\fulltablegrid[black!25,ystep=1,xstep=2]
\tablerules
\end{extracode}
\end{tikztimingtable}
\caption{\texttt{GET_SAMPLE_REJECTED_STATUS} and \texttt{GET_REQUESTED_DEADLINE_MISSED_STATUS} \acrshort{DDS} Operations}
\label{tim:get-sample-rejected-status}
\end{timingdiag}
\subsection{\acrshort{DDS} Writer}
\label{tim:dds-writer}
\begin{timingdiag}
\centering
\begin{tikztimingtable}
clk & [L]12{CC}\\
\color{Red} start & [L]{LL}2{HH}9{LL}\\
\color{Red} opcode & {UU}{DDDD}9{UU}\\
\color{Red} instance_handle_in & 12{UU}\\
\color{Red} source_ts & 12{UU}\\
\color{Red} max_wait & 12{UU}\\
\color{Blue}ack & [L]2{LL}{HH}9{LL}\\
\color{Red} valid_in & [L]3{LL}2{HH}{LL}2{HH};[dotted]HH;{HH}2{LL}\\
\color{Blue}ready_in & [L]4{LL}{HH}{LL}2{HH};[dotted]HH;{HH}2{LL}\\
\color{Red} data_in & 3{UU}2{DD}{}{UU}2{DD{}};[dotted]DD{};{DD}2{UU}\\
\color{Red} last_word_in & [L]8{LL};[dotted]LL;{HH}2{LL}\\
\color{Blue}done & [L]10{LL}{HH}{LL}\\
\color{Blue}return_code & 10{UU}1{DD}{OK}{UU}\\
\color{Blue}instance_handle_out & 10{UU}{DD}{UU}\\
\color{Blue}valid_out & [L]12{LL}\\
\color{Red} ready_out & [L]12{LL}\\
\color{Blue}data_out & 12{UU}\\
\color{Blue}last_word_out & [L]12{LL}\\
\begin{extracode}
\tableheader{Signal}{Relation}
\fulltablegrid[black!25,ystep=1,xstep=2]
\tablerules
\end{extracode}
\end{tikztimingtable}
\caption{\texttt{REGISTER_INSTANCE}, \texttt{LOOKUP_INSTANCE} \acrshort{DDS} Operations}
\label{tim:register-instance}
\end{timingdiag}
\begin{timingdiag}
\centering
\begin{tikztimingtable}
clk & [L]12{CC}\\
\color{Red} start & [L]{LL}2{HH}9{LL}\\
\color{Red} opcode & {UU}{DDDD}9{UU}\\
\color{Red} instance_handle_in & {UU}{DDDD}9{UU}\\
\color{Red} source_ts & {UU}{DDDD}9{UU}\\
\color{Red} max_wait & 12{UU}\\
\color{Blue}ack & [L]2{LL}{HH}9{LL}\\
\color{Red} valid_in & [L]3{LL}2{HH}{LL}2{HH};[dotted]HH;{HH}2{LL}\\
\color{Blue}ready_in & [L]4{LL}{HH}{LL}2{HH};[dotted]HH;{HH}2{LL}\\
\color{Red} data_in & 3{UU}2{DD}{}{UU}2{DD{}};[dotted]DD{};{DD}2{UU}\\
\color{Red} last_word_in & [L]8{LL};[dotted]LL;{HH}2{LL}\\
\color{Blue}done & [L]10{LL}{HH}{LL}\\
\color{Blue}return_code & 10{UU}1{DD}{OK}{UU}\\
\color{Blue}instance_handle_out & 12{UU}\\
\color{Blue}valid_out & [L]12{LL}\\
\color{Red} ready_out & [L]12{LL}\\
\color{Blue}data_out & 12{UU}\\
\color{Blue}last_word_out & [L]12{LL}\\
\begin{extracode}
\tableheader{Signal}{Relation}
\fulltablegrid[black!25,ystep=1,xstep=2]
\tablerules
\end{extracode}
\end{tikztimingtable}
\caption{\texttt{WRITE}, \texttt{DISPOSE}, and \texttt{UNREGISTER_INSTANCE} \acrshort{DDS} Operations}
\label{tim:write}
\end{timingdiag}
\begin{timingdiag}
\centering
\begin{tikztimingtable}
clk & [L]13{CC}\\
\color{Red} start & [L]{LL}2{HH}10{LL}\\
\color{Red} opcode & {UU}1{DDDD}{\tiny GET}10{UU}\\
\color{Red} instance_handle_in & 13{UU}\\
\color{Red} source_ts & 13{UU}\\
\color{Red} max_wait & 13{UU}\\
\color{Blue}ack & [L]2{LL}{HH}10{LL}\\
\color{Red} valid_in & [L]13{LL}\\
\color{Blue}ready_in & [L]13{LL}\\
\color{Red} data_in & 13{UU}\\
\color{Red} last_word_in & [L]13{LL}\\
\color{Blue}done & [L]4{LL}{HH}8{LL}\\
\color{Blue}return_code & 4{UU}1{DD}{OK}8{UU}\\
\color{Blue}instance_handle_out & 13{UU}\\
\color{Blue}valid_out & [L]5{LL}2{HH}{LL}2{HH};[dotted]HH;{HH}1{LL}\\
\color{Red} ready_out & [L]6{LL}{HH}{LL}2{HH};[dotted]HH;{HH}1{LL}\\
\color{Blue}data_out & 5{UU}2{DD}{}{UU}2{DD{}};[dotted]DD{};{DD}1{UU}\\
\color{Blue}last_word_out & [L]10{LL};[dotted]LL;{HH}1{LL}\\
\begin{extracode}
\tableheader{Signal}{Relation}
\fulltablegrid[black!25,ystep=1,xstep=2]
\tablerules
\end{extracode}
\end{tikztimingtable}
\caption{\texttt{GET_OFFERED_DEADLINE_MISSED_STATUS} and \texttt{GET_LIVELINESS_LOST_STATUS} \acrshort{DDS} Operations}
\label{tim:get-offered-deadline-missded-status}
\end{timingdiag}
\begin{timingdiag}
\centering
\begin{tikztimingtable}
clk & [L]8{CC}\\
\color{Red} start & [L]{LL}2{HH}5{LL}\\
\color{Red} opcode & {UU}1{DDDD}{\tiny WAIT}5{UU}\\
\color{Red} instance_handle_in & 8{UU}\\
\color{Red} source_ts & 8{UU}\\
\color{Red} max_wait & {UU}{DDDD}5{UU}\\
\color{Blue}ack & [L]2{LL}{HH}5{LL}\\
\color{Red} valid_in & [L]8{LL}\\
\color{Blue}ready_in & [L]8{LL}\\
\color{Red} data_in & 8{UU}\\
\color{Red} last_word_in & [L]8{LL}\\
\color{Blue}done & [L]6{LL}{HH}{LL}\\
\color{Blue}return_code & 6{UU}1{DD}{OK}{UU}\\
\color{Blue}instance_handle_out & 8{UU}\\
\color{Blue}valid_out & [L]8{LL}\\
\color{Red} ready_out & [L]8{LL}\\
\color{Blue}data_out & 8{UU}\\
\color{Blue}last_word_out & [L]8{LL}\\
\begin{extracode}
\tableheader{Signal}{Relation}
\fulltablegrid[black!25,ystep=1,xstep=2]
\tablerules
\end{extracode}
\end{tikztimingtable}
\caption{\texttt{WAIT_FOR_ACKNOWLEDGEMENTS} \acrshort{DDS} Operations}
\label{tim:wait-for-acknowledgements}
\end{timingdiag}
\begin{timingdiag}
\centering
\begin{tikztimingtable}
clk & [L]8{CC}\\
\color{Red} start & [L]{LL}2{HH}5{LL}\\
\color{Red} opcode & {UU}1{DDDD}{\tiny ASSERT}5{UU}\\
\color{Red} instance_handle_in & 8{UU}\\
\color{Red} source_ts & 8{UU}\\
\color{Red} max_wait & 8{UU}\\
\color{Blue}ack & [L]2{LL}{HH}5{LL}\\
\color{Red} valid_in & [L]8{LL}\\
\color{Blue}ready_in & [L]8{LL}\\
\color{Red} data_in & 8{UU}\\
\color{Red} last_word_in & [L]8{LL}\\
\color{Blue}done & [L]6{LL}{HH}{LL}\\
\color{Blue}return_code & 6{UU}1{DD}{OK}{UU}\\
\color{Blue}instance_handle_out & 8{UU}\\
\color{Blue}valid_out & [L]8{LL}\\
\color{Red} ready_out & [L]8{LL}\\
\color{Blue}data_out & 8{UU}\\
\color{Blue}last_word_out & [L]8{LL}\\
\begin{extracode}
\tableheader{Signal}{Relation}
\fulltablegrid[black!25,ystep=1,xstep=2]
\tablerules
\end{extracode}
\end{tikztimingtable}
\caption{\texttt{ASSERT_LIVELINESS} \acrshort{DDS} Operations}
\label{tim:assert-liveliness}
\end{timingdiag}
\subsection{Reader/Writer Interface}
\label{tim:reader-writer-interface}
\begin{timingdiag}
\centering
\begin{tikztimingtable}
clk & [L]21{CC}\\
\color{Red} start & [L]{LL}2{HH}18{LL}\\
\color{Red} opcode & {UU}{DDDD}18{UU}\\
\color{Red} sample_state & {UU}{DDDD}18{UU}\\
\color{Red} view_state & {UU}{DDDD}18{UU}\\
\color{Red} instance_state & {UU}{DDDD}18{UU}\\
\color{Red} max_samples & {UU}{DDDD}18{UU}\\
\color{Red} instance_handle & 21{UU}\\
\color{Blue}ack & [L]2{LL}{HH}18{LL}\\
\color{Blue}done & [L]4{LL}{HH}16{LL}\\
\color{Blue}return_code & 4{UU}1{DD}{OK}16{UU}\\
\color{Blue}sample_info_valid & [L]6{LL}2{HH}{LL}{HH}2{LL}{HH}{LL}{HH}{LL};[dotted]LL;{HH}3{LL}\\
\color{Blue}sample_info & 6{UU}2{DD}{A}{UU}{DD{B}}2{UU}{DD{C}}{UU}{DD{D}}{UU};[dotted]DD{};{DD}3{UU}\\
\color{Red} sample_info_ack & [L]7{LL}{HH}{LL}{HH}2{LL}{HH}{LL}{HH}{LL};[dotted]LL;{HH}3{LL}\\
\color{Red} get_data & [L]9{LL}{HH}4{LL}{HH}{LL};[dotted]LL;4{LL}\\
\color{Blue}{\tiny <TYPENAME>_}valid & [L]11{LL}4{HH}{LL};[dotted]LL;4{LL}\\
\color{Blue}{\tiny <TYPENAME_SIGNALS>} & 11{UU}4{DD}{B}{UU};[dotted]DD{};4{UU}\\
\color{Blue}decode_error & [L]16{LL};[dotted]LL;4{LL}\\
\color{Blue}eoc & [L]16{LL};[dotted]LL;2{LL}{HH}{LL}\\
\color{Blue}valid_out & [L]21{LL}\\
\color{Red} ready_out & [L]21{LL}\\
\color{Blue}data_out & 21{UU}\\
\color{Blue}last_word_out & [L]21{LL}\\
\begin{extracode}
\tableheader{Signal}{Relation}
\fulltablegrid[black!25,ystep=1,xstep=2]
\tablerules
\end{extracode}
\end{tikztimingtable}
\caption{\texttt{READ} and \texttt{TAKE} \acrshort{DDS} Operations through <TYPENAME>_READER_INTERFACE.}
\label{tim:interface-read}
\end{timingdiag}
\begin{timingdiag}
\centering
\begin{tikztimingtable}
clk & [L]21{CC}\\
\color{Red} start & [L]{LL}2{HH}18{LL}\\
\color{Red} opcode & {UU}{DDDD}18{UU}\\
\color{Red} sample_state & {UU}{DDDD}18{UU}\\
\color{Red} view_state & {UU}{DDDD}18{UU}\\
\color{Red} instance_state & {UU}{DDDD}18{UU}\\
\color{Red} max_samples & {UU}{DDDD}18{UU}\\
\color{Red} instance_handle & 21{UU}\\
\color{Blue}ack & [L]2{LL}{HH}18{LL}\\
\color{Blue}done & [L]4{LL}{HH}16{LL}\\
\color{Blue}return_code & 4{UU}1{DD}{OK}16{UU}\\
\color{Blue}sample_info_valid & [L]6{LL}2{HH}{LL}{HH}2{LL}{HH}{LL}{HH}{LL};[dotted]LL;{HH}3{LL}\\
\color{Blue}sample_info & 6{UU}2{DD}{A}{UU}{DD{B}}2{UU}{DD{C}}{UU}{DD{D}}{UU};[dotted]DD{};{DD}3{UU}\\
\color{Red} sample_info_ack & [L]7{LL}{HH}{LL}{HH}2{LL}{HH}{LL}{HH}{LL};[dotted]LL;{HH}3{LL}\\
\color{Red} get_data & [L]9{LL}{HH}4{LL}{HH}{LL};[dotted]LL;4{LL}\\
\color{Blue}{\tiny <TYPENAME>_}valid & [L]16{LL};[dotted]LL;4{LL}\\
\color{Blue}{\tiny <TYPENAME_SIGNALS>} & 21{UU}\\
\color{Blue}decode_error & [L]11{LL}4{HH}{LL};[dotted]LL;4{LL}\\
\color{Blue}eoc & [L]16{LL};[dotted]LL;2{LL}{HH}{LL}\\
\color{Blue}valid_out & [L]21{LL}\\
\color{Red} ready_out & [L]21{LL}\\
\color{Blue}data_out & 21{UU}\\
\color{Blue}last_word_out & [L]21{LL}\\
\begin{extracode}
\tableheader{Signal}{Relation}
\fulltablegrid[black!25,ystep=1,xstep=2]
\tablerules
\end{extracode}
\end{tikztimingtable}
\caption{\texttt{READ} and \texttt{TAKE} \acrshort{DDS} Operations through <TYPENAME>_READER_INTERFACE with decode error.}
\label{tim:interface-read-decode-error}
\end{timingdiag}
\begin{timingdiag}
\centering
\begin{tikztimingtable}
clk & [L]21{CC}\\
\color{Red} start & [L]{LL}2{HH}7{LL}{HH}3{LL}{HH}6{LL}\\
\color{Red} opcode & {UU}2{DD}7{UU}{DD}3{UU}{DD}6{UU}\\
\color{Red} sample_state & 21{UU}\\
\color{Red} view_state & 21{UU}\\
\color{Red} instance_state & 21{UU}\\
\color{Red} max_samples & 21{UU}\\
\color{Red} instance_handle & 21{UU}\\
\color{Blue}ack & [L]2{LL}{HH}7{LL}{HH}3{LL}{HH}6{LL}\\
\color{Blue}done & [L]4{LL}{HH}6{LL}{HH}3{LL}{HH}5{LL}\\
\color{Blue}return_code & 4{UU}1{DD}{OK}6{UU}1{DD}{OK}3{UU}1{DD}{OK}5{UU}\\
\color{Blue}sample_info_valid & [L]6{LL}2{HH}4{LL}{HH}3{LL}{HH}4{LL}\\
\color{Blue}sample_info & 6{UU}2{DD}{A}4{UU}{DD{B}}3{UU}{DD{C}}4{UU}\\
\color{Red} sample_info_ack & [L]7{LL}{HH}4{LL}{HH}3{LL}{HH}4{LL}\\
\color{Red} get_data & [L]7{LL}{HH}8{LL}{HH}4{LL}\\
\color{Blue}{\tiny <TYPENAME>_}valid & [L]8{LL}9{HH}{LL}3{HH}\\
\color{Blue}{\tiny <TYPENAME_SIGNALS>} & 8{UU}9{DD}{A}{UU}3{DD}{C}\\
\color{Blue}decode_error & [L]21{LL}\\
\color{Blue}eoc & [L]9{LL}{HH}3{LL}{HH}5{LL}{HH}{LL}\\
\color{Blue}valid_out & [L]21{LL}\\
\color{Red} ready_out & [L]21{LL}\\
\color{Blue}data_out & 21{UU}\\
\color{Blue}last_word_out & [L]21{LL}\\
\begin{extracode}
\tableheader{Signal}{Relation}
\fulltablegrid[black!25,ystep=1,xstep=2]
\tablerules
\end{extracode}
\end{tikztimingtable}
\caption{\texttt{READ_NEXT_SAMPLE} and \texttt{TAKE_NEXT_SAMPLE} \acrshort{DDS} Operations through <TYPENAME>_READER_INTERFACE}
\label{tim:interface-read-next-sample}
\end{timingdiag}
\begin{timingdiag}
\centering
\begin{tikztimingtable}
clk & [L]21{CC}\\
\color{Red} start & [L]{LL}2{HH}7{LL}{HH}3{LL}{HH}6{LL}\\
\color{Red} opcode & {UU}2{DD}7{UU}{DD}3{UU}{DD}6{UU}\\
\color{Red} sample_state & 21{UU}\\
\color{Red} view_state & 21{UU}\\
\color{Red} instance_state & 21{UU}\\
\color{Red} max_samples & 21{UU}\\
\color{Red} instance_handle & 21{UU}\\
\color{Blue}ack & [L]2{LL}{HH}7{LL}{HH}3{LL}{HH}6{LL}\\
\color{Blue}done & [L]4{LL}{HH}6{LL}{HH}3{LL}{HH}5{LL}\\
\color{Blue}return_code & 4{UU}1{DD}{OK}6{UU}1{DD}{OK}3{UU}1{DD}{OK}5{UU}\\
\color{Blue}sample_info_valid & [L]6{LL}2{HH}4{LL}{HH}3{LL}{HH}4{LL}\\
\color{Blue}sample_info & 6{UU}2{DD}{A}4{UU}{DD{B}}3{UU}{DD{C}}4{UU}\\
\color{Red} sample_info_ack & [L]7{LL}{HH}4{LL}{HH}3{LL}{HH}4{LL}\\
\color{Red} get_data & [L]7{LL}{HH}8{LL}{HH}4{LL}\\
\color{Blue}{\tiny <TYPENAME>_}valid & [L]18{LL}3{HH}\\
\color{Blue}{\tiny <TYPENAME_SIGNALS>} & 18{UU}3{DD}{C}\\
\color{Blue}decode_error & [L]8{LL}9{HH}4{LL}\\
\color{Blue}eoc & [L]9{LL}{HH}3{LL}{HH}5{LL}{HH}{LL}\\
\color{Blue}valid_out & [L]21{LL}\\
\color{Red} ready_out & [L]21{LL}\\
\color{Blue}data_out & 21{UU}\\
\color{Blue}last_word_out & [L]21{LL}\\
\begin{extracode}
\tableheader{Signal}{Relation}
\fulltablegrid[black!25,ystep=1,xstep=2]
\tablerules
\end{extracode}
\end{tikztimingtable}
\caption{\texttt{READ_NEXT_SAMPLE} and \texttt{TAKE_NEXT_SAMPLE} \acrshort{DDS} Operations through <TYPENAME>_READER_INTERFACE with decode error.}
\label{tim:interface-read-next-sample-decode-error}
\end{timingdiag}
\begin{timingdiag}
\centering
\begin{tikztimingtable}
clk & [L]21{CC}\\
\color{Red} start & [L]{LL}2{HH}18{LL}\\
\color{Red} opcode & {UU}{DDDD}18{UU}\\
\color{Red} sample_state & {UU}{DDDD}18{UU}\\
\color{Red} view_state & {UU}{DDDD}18{UU}\\
\color{Red} instance_state & {UU}{DDDD}18{UU}\\
\color{Red} max_samples & {UU}{DDDD}18{UU}\\
\color{Red} instance_handle & {UU}{DDDD}18{UU}\\
\color{Blue}ack & [L]2{LL}{HH}18{LL}\\
\color{Blue}done & [L]4{LL}{HH}16{LL}\\
\color{Blue}return_code & 4{UU}1{DD}{OK}16{UU}\\
\color{Blue}sample_info_valid & [L]6{LL}2{HH}{LL}{HH}2{LL}{HH}{LL}{HH}{LL};[dotted]LL;{HH}3{LL}\\
\color{Blue}sample_info & 6{UU}2{DD}{A}{UU}{DD{B}}2{UU}{DD{C}}{UU}{DD{D}}{UU};[dotted]DD{};{DD}3{UU}\\
\color{Red} sample_info_ack & [L]7{LL}{HH}{LL}{HH}2{LL}{HH}{LL}{HH}{LL};[dotted]LL;{HH}3{LL}\\
\color{Red} get_data & [L]9{LL}{HH}4{LL}{HH}{LL};[dotted]LL;4{LL}\\
\color{Blue}{\tiny <TYPENAME>_}valid & [L]11{LL}4{HH}{LL};[dotted]LL;4{LL}\\
\color{Blue}{\tiny <TYPENAME_SIGNALS>} & 11{UU}4{DD}{B}{UU};[dotted]DD{};4{UU}\\
\color{Blue}decode_error & [L]16{LL};[dotted]LL;4{LL}\\
\color{Blue}eoc & [L]16{LL};[dotted]LL;2{LL}{HH}{LL}\\
\color{Blue}valid_out & [L]21{LL}\\
\color{Red} ready_out & [L]21{LL}\\
\color{Blue}data_out & 21{UU}\\
\color{Blue}last_word_out & [L]21{LL}\\
\begin{extracode}
\tableheader{Signal}{Relation}
\fulltablegrid[black!25,ystep=1,xstep=2]
\tablerules
\end{extracode}
\end{tikztimingtable}
\caption{\texttt{READ_INSTANCE}, \texttt{TAKE_INSTANCE}, \texttt{READ_NEXT_INSTANCE}, and \texttt{TAKE_NEXT_INSTANCE} \acrshort{DDS} Operations through <TYPENAME>_READER_INTERFACE.}
\label{tim:interface-read-instance}
\end{timingdiag}
\begin{timingdiag}
\centering
\begin{tikztimingtable}
clk & [L]13{CC}\\
\color{Red} start & [L]{LL}2{HH}10{LL}\\
\color{Red} opcode & {UU}1{DDDD}{\tiny GET}10{UU}\\
\color{Red} sample_state & 13{UU}\\
\color{Red} view_state & 13{UU}\\
\color{Red} instance_state & 13{UU}\\
\color{Red} max_samples & 13{UU}\\
\color{Red} instance_handle & 13{UU}\\
\color{Blue}ack & [L]2{LL}{HH}10{LL}\\
\color{Blue}done & [L]4{LL}{HH}8{LL}\\
\color{Blue}return_code & 4{UU}1{DD}{OK}8{UU}\\
\color{Blue}sample_info_valid & [L]13{LL}\\
\color{Blue}sample_info & 13{UU}\\
\color{Red} sample_info_ack & [L]13{LL}\\
\color{Red} get_data & [L]13{LL}\\
\color{Blue}{\tiny <TYPENAME>_}valid & [L]13{LL}\\
\color{Blue}{\tiny <TYPENAME_SIGNALS>} & 13{UU}\\
\color{Blue}decode_error & [L]13{LL}\\
\color{Blue}eoc & [L]13{LL}\\
\color{Blue}valid_out & [L]5{LL}2{HH}{LL}2{HH};[dotted]HH;{HH}1{LL}\\
\color{Red} ready_out & [L]6{LL}{HH}{LL}2{HH};[dotted]HH;{HH}1{LL}\\
\color{Blue}data_out & 5{UU}2{DD}{}{UU}2{DD{}};[dotted]DD{};{DD}1{UU}\\
\color{Blue}last_word_out & [L]10{LL};[dotted]LL;{HH}1{LL}\\
\begin{extracode}
\tableheader{Signal}{Relation}
\fulltablegrid[black!25,ystep=1,xstep=2]
\tablerules
\end{extracode}
\end{tikztimingtable}
\caption{\texttt{GET_SAMPLE_REJECTED_STATUS} and \texttt{GET_REQUESTED_DEADLINE_MISSED_STATUS} \acrshort{DDS} Operations through <TYPENAME>_READER_INTERFACE.}
\label{tim:interface-get-sample-rejected-status}
\end{timingdiag}
\begin{timingdiag}
\centering
\begin{tikztimingtable}
clk & [L]8{CC}\\
\color{Red} start & [L]{LL}2{HH}5{LL}\\
\color{Red} opcode & {UU}{DDDD}5{UU}\\
\color{Red} instance_handle_in & 8{UU}\\
\color{Red} source_ts & 8{UU}\\
\color{Red} max_wait & 8{UU}\\
\color{Blue}ack & [L]2{LL}{HH}5{LL}\\
\color{Red} {\tiny <TYPENAME_SIGNALS>} & {UU}4{DD}3{UU}\\
\color{Blue}encode_done & [L]4{LL}{HH}3{LL}\\
\color{Blue}done & [L]6{LL}{HH}{LL}\\
\color{Blue}return_code & 6{UU}1{DD}{OK}{UU}\\
\color{Blue}instance_handle_out & 6{UU}{DD}{UU}\\
\color{Blue}valid_out & [L]8{LL}\\
\color{Red} ready_out & [L]8{LL}\\
\color{Blue}data_out & 8{UU}\\
\color{Blue}last_word_out & [L]8{LL}\\
\begin{extracode}
\tableheader{Signal}{Relation}
\fulltablegrid[black!25,ystep=1,xstep=2]
\tablerules
\end{extracode}
\end{tikztimingtable}
\caption{\texttt{REGISTER_INSTANCE}, \texttt{LOOKUP_INSTANCE} \acrshort{DDS} Operations through <TYPENAME>_WRITER_INTERFACE.}
\label{tim:interface-register-instance}
\end{timingdiag}
\begin{timingdiag}
\centering
\begin{tikztimingtable}
clk & [L]8{CC}\\
\color{Red} start & [L]{LL}2{HH}5{LL}\\
\color{Red} opcode & {UU}{DDDD}5{UU}\\
\color{Red} instance_handle_in & {UU}{DDDD}5{UU}\\
\color{Red} source_ts & {UU}{DDDD}5{UU}\\
\color{Red} max_wait & 8{UU}\\
\color{Blue}ack & [L]2{LL}{HH}5{LL}\\
\color{Red} {\tiny <TYPENAME_SIGNALS>} & {UU}4{DD}3{UU}\\
\color{Blue}encode_done & [L]4{LL}{HH}3{LL}\\
\color{Blue}done & [L]6{LL}{HH}{LL}\\
\color{Blue}return_code & 6{UU}1{DD}{OK}{UU}\\
\color{Blue}instance_handle_out & 6{UU}{DD}{UU}\\
\color{Blue}valid_out & [L]8{LL}\\
\color{Red} ready_out & [L]8{LL}\\
\color{Blue}data_out & 8{UU}\\
\color{Blue}last_word_out & [L]8{LL}\\
\begin{extracode}
\tableheader{Signal}{Relation}
\fulltablegrid[black!25,ystep=1,xstep=2]
\tablerules
\end{extracode}
\end{tikztimingtable}
\caption{\texttt{WRITE}, \texttt{DISPOSE}, and \texttt{UNREGISTER_INSTANCE} \acrshort{DDS} Operations through <TYPENAME>_WRITER_INTERFACE.}
\label{tim:interface-write}
\end{timingdiag}
\begin{timingdiag}
\centering
\begin{tikztimingtable}
clk & [L]13{CC}\\
\color{Red} start & [L]{LL}2{HH}10{LL}\\
\color{Red} opcode & {UU}1{DDDD}{\tiny GET}10{UU}\\
\color{Red} instance_handle_in & 13{UU}\\
\color{Red} source_ts & 13{UU}\\
\color{Red} max_wait & 13{UU}\\
\color{Blue}ack & [L]2{LL}{HH}10{LL}\\
\color{Red} {\tiny <TYPENAME_SIGNALS>} & 13{UU}\\
\color{Blue}encode_done & [L]13{LL}\\
\color{Blue}done & [L]4{LL}{HH}8{LL}\\
\color{Blue}return_code & 4{UU}1{DD}{OK}8{UU}\\
\color{Blue}instance_handle_out & 13{UU}\\
\color{Blue}valid_out & [L]5{LL}2{HH}{LL}2{HH};[dotted]HH;{HH}1{LL}\\
\color{Red} ready_out & [L]6{LL}{HH}{LL}2{HH};[dotted]HH;{HH}1{LL}\\
\color{Blue}data_out & 5{UU}2{DD}{}{UU}2{DD{}};[dotted]DD{};{DD}1{UU}\\
\color{Blue}last_word_out & [L]10{LL};[dotted]LL;{HH}1{LL}\\
\begin{extracode}
\tableheader{Signal}{Relation}
\fulltablegrid[black!25,ystep=1,xstep=2]
\tablerules
\end{extracode}
\end{tikztimingtable}
\caption{\texttt{GET_OFFERED_DEADLINE_MISSED_STATUS} and \texttt{GET_LIVELINESS_LOST_STATUS} \acrshort{DDS} Operations through <TYPENAME>_WRITER_INTERFACE.}
\label{tim:interface-get-offered-deadline-missded-status}
\end{timingdiag}
\begin{timingdiag}
\centering
\begin{tikztimingtable}
clk & [L]8{CC}\\
\color{Red} start & [L]{LL}2{HH}5{LL}\\
\color{Red} opcode & {UU}1{DDDD}{\tiny WAIT}5{UU}\\
\color{Red} instance_handle_in & 8{UU}\\
\color{Red} source_ts & 8{UU}\\
\color{Red} max_wait & {UU}{DDDD}5{UU}\\
\color{Blue}ack & [L]2{LL}{HH}5{LL}\\
\color{Red} {\tiny <TYPENAME_SIGNALS>} & 8{UU}\\
\color{Blue}encode_done & [L]8{LL}\\
\color{Blue}done & [L]6{LL}{HH}{LL}\\
\color{Blue}return_code & 6{UU}1{DD}{OK}{UU}\\
\color{Blue}instance_handle_out & 8{UU}\\
\color{Blue}valid_out & [L]8{LL}\\
\color{Red} ready_out & [L]8{LL}\\
\color{Blue}data_out & 8{UU}\\
\color{Blue}last_word_out & [L]8{LL}\\
\begin{extracode}
\tableheader{Signal}{Relation}
\fulltablegrid[black!25,ystep=1,xstep=2]
\tablerules
\end{extracode}
\end{tikztimingtable}
\caption{\texttt{WAIT_FOR_ACKNOWLEDGEMENTS} \acrshort{DDS} Operations through <TYPENAME>_WRITER_INTERFACE.}
\label{tim:interface-wait-for-acknowledgements}
\end{timingdiag}
\begin{timingdiag}
\centering
\begin{tikztimingtable}
clk & [L]8{CC}\\
\color{Red} start & [L]{LL}2{HH}5{LL}\\
\color{Red} opcode & {UU}1{DDDD}{\tiny ASSERT}5{UU}\\
\color{Red} instance_handle_in & 8{UU}\\
\color{Red} source_ts & 8{UU}\\
\color{Red} max_wait & 8{UU}\\
\color{Blue}ack & [L]2{LL}{HH}5{LL}\\
\color{Red} {\tiny <TYPENAME_SIGNALS>} & 8{UU}\\
\color{Blue}encode_done & [L]8{LL}\\
\color{Blue}done & [L]6{LL}{HH}{LL}\\
\color{Blue}return_code & 6{UU}1{DD}{OK}{UU}\\
\color{Blue}instance_handle_out & 8{UU}\\
\color{Blue}valid_out & [L]8{LL}\\
\color{Red} ready_out & [L]8{LL}\\
\color{Blue}data_out & 8{UU}\\
\color{Blue}last_word_out & [L]8{LL}\\
\begin{extracode}
\tableheader{Signal}{Relation}
\fulltablegrid[black!25,ystep=1,xstep=2]
\tablerules
\end{extracode}
\end{tikztimingtable}
\caption{\texttt{ASSERT_LIVELINESS} \acrshort{DDS} Operations through <TYPENAME>_WRITER_INTERFACE.}
\label{tim:interface-assert-liveliness}
\end{timingdiag}
\begin{timingdiag}
\centering
\begin{tikztimingtable}
clk & [L]14{CC}\\
\color{Blue}{\tiny <ARRAYNAME>_}len & {UU}12{DD}{}{UU}\\
\color{Red} {\tiny <ARRAYNAME>_}addr & 2{UU}{DD{A}}4{UU}2{DD}{B}{DD{C}}{DD{D}}3{UU}\\
\color{Blue}{\tiny <ARRAYNAME>_}ready & [L]{LL}2{HH}5{LL}3{HH}3{LL}\\
\color{Red} {\tiny <ARRAYNAME>_}ren & [L]2{LL}{HH}4{LL}4{HH}3{LL}\\
\color{Blue}{\tiny <ARRAYNAME>} & 4{UU}2{DD}{A}3{UU}{DD{B}}{DD{C}}{DD{D}}2{UU}\\
\color{Blue}{\tiny <ARRAYNAME>_}valid & [L]4{LL}2{HH}3{LL}3{HH}2{LL}\\
\color{Red} {\tiny <ARRAYNAME>_}ack & [L]5{LL}{HH}3{LL}3{HH}2{LL}\\
\color{Blue}{\tiny <TYPENAME>_}valid & [L]{LL}12{HH}{LL}\\
\begin{extracode}
\tableheader{Signal}{Relation}
\fulltablegrid[black!25,ystep=1,xstep=2]
\tablerules
\end{extracode}
\end{tikztimingtable}
\caption{Array access through <TYPENAME>_READER_INTERFACE.}
\label{tim:reader-interface-array}
\end{timingdiag}
\begin{timingdiag}
\centering
\begin{tikztimingtable}
clk & [L]13{CC}\\
\color{Red} {\tiny <ARRAYNAME>_}addr & 2{UU}{DD{A}}2{DD}{B}{DD{C}}2{DD}{A}{UU}{DD{C}}3{UU}\\
\color{Blue}{\tiny <ARRAYNAME>_}ready & [L]{LL}2{HH}{LL}2{HH}{LL}3{HH}3{LL}\\
\color{Red} {\tiny <ARRAYNAME>_}wen & [L]2{LL}4{HH}7{LL}\\
\color{Red} {\tiny <ARRAYNAME>_}ren & [L]6{LL}2{HH}{LL}{HH}3{LL}\\
\color{Red} {\tiny <ARRAYNAME>_}w & 2{UU}{DD{A}}2{DD}{B}{DD{C}}7{UU}\\
\color{Blue}{\tiny <ARRAYNAME>_}r & 8{UU}3{DD}{A}{DD{C}}{UU}\\
\color{Blue}{\tiny <ARRAYNAME>_}valid & [L]8{LL}4{HH}{LL}\\
\color{Red} {\tiny <ARRAYNAME>_}ack & [L]10{LL}2{HH}{LL}\\
\begin{extracode}
\tableheader{Signal}{Relation}
\fulltablegrid[black!25,ystep=1,xstep=2]
\tablerules
\end{extracode}
\end{tikztimingtable}
\caption{Array access through <TYPENAME>_WRITER_INTERFACE.}
\label{tim:writer-interface-array}
\end{timingdiag}
\subsection{Key Holder}
\label{tim:key-holder}
\begin{timingdiag}
\centering
\begin{tikztimingtable}
clk & [L]12{CC}\\
\color{Red} start & [L]{LL}2{HH}9{LL}\\
\color{Red} opcode & {UU}1{DDDD}{\tiny PUSH}9{UU}\\
\color{Red} abort & [L]12{LL}\\
\color{Blue}ack & [L]2{LL}{HH}9{LL}\\
\color{Red} valid_in & [L]3{LL}2{HH}{LL}2{HH};[dotted]HH;{HH}2{LL}\\
\color{Blue}ready_in & [L]4{LL}{HH}{LL}2{HH};[dotted]HH;{HH}2{LL}\\
\color{Red} data_in & 3{UU}2{DD}{}{UU}2{DD{}};[dotted]DD{};{DD}2{UU}\\
\color{Red} last_word_in & [L]8{LL};[dotted]LL;{HH}2{LL}\\
\color{Blue}valid_out & [L]12{LL}\\
\color{Red} ready_out & [L]12{LL}\\
\color{Blue}data_out & 12{UU}\\
\color{Blue}last_word_out & [L]12{LL}\\
\color{Blue}decode_error & [L]12{LL}\\
\begin{extracode}
\tableheader{Signal}{Relation}
\fulltablegrid[black!25,ystep=1,xstep=2]
\tablerules
\end{extracode}
\end{tikztimingtable}
\caption{\texttt{PUSH_DATA} and \texttt{PUSH_SERIALIZED_KEY} Key Holder Operation.}
\label{tim:key-holder-push-data}
\end{timingdiag}
\begin{timingdiag}
\centering
\begin{tikztimingtable}
clk & [L]16{CC}\\
\color{Red} start & [L]{LL}2{HH}8{LL}{HH}4{LL}\\
\color{Red} opcode & {UU}1{DDDD}{\tiny PUSH}8{UU}1{DD}{\tiny PUSH}4{UU}\\
\color{Red} abort & [L]16{LL}\\
\color{Blue}ack & [L]2{LL}{HH}8{LL}{HH}4{LL}\\
\color{Red} valid_in & [L]3{LL}2{HH}{LL}2{HH};[dotted]HH;{HH}2{LL}{HH};[dotted]HH;{HH}{LL}\\
\color{Blue}ready_in & [L]4{LL}{HH}{LL}2{HH};[dotted]HH;{HH}2{LL}{HH};[dotted]HH;{HH}{LL}\\
\color{Red} data_in & 3{UU}2{DD}{}{UU}2{DD{}};[dotted]DD{};{DD}2{UU}{DD{}};[dotted]DD{};{DD}{UU}\\
\color{Red} last_word_in & [L]8{LL};[dotted]LL;{HH}3{LL};[dotted]LL;{HH}{LL}\\
\color{Blue}valid_out & [L]16{LL}\\
\color{Red} ready_out & [L]16{LL}\\
\color{Blue}data_out & 16{UU}\\
\color{Blue}last_word_out & [L]16{LL}\\
\color{Blue}decode_error & [L]5{LL}7{HH}4{LL}\\
\begin{extracode}
\tableheader{Signal}{Relation}
\fulltablegrid[black!25,ystep=1,xstep=2]
\tablerules
\end{extracode}
\end{tikztimingtable}
\caption{\texttt{PUSH_DATA} and \texttt{PUSH_SERIALIZED_KEY} Key Holder Operation with decode error.}
\label{tim:key-holder-decode-error}
\end{timingdiag}
\begin{timingdiag}
\centering
\begin{tikztimingtable}
clk & [L]8{CC}\\
\color{Red} start & [L]{LL}2{HH}3{LL}{UU}{LL}\\
\color{Red} opcode & {UU}{DDDD}5{UU}\\
\color{Red} abort & [L]6{LL}{HH}{LL}\\
\color{Blue}ack & [L]2{LL}{HH}5{LL}\\
\color{Red} valid_in & [L]3{LL}2{HH}{LL}1{UU}{LL}\\
\color{Blue}ready_in & [L]4{LL}{HH}3{LL}\\
\color{Red} data_in & 3{UU}2{DD}{}{UU}2{UU}\\
\color{Red} last_word_in & [L]6{LL}{UU}{LL}\\
\color{Blue}valid_out & [L]8{LL}\\
\color{Red} ready_out & [L]6{LL}{UU}{LL}\\
\color{Blue}data_out & 8{UU}\\
\color{Blue}last_word_out & [L]8{LL}\\
\color{Blue}decode_error & [L]8{LL}\\
\begin{extracode}
\tableheader{Signal}{Relation}
\fulltablegrid[black!25,ystep=1,xstep=2]
\tablerules
\end{extracode}
\end{tikztimingtable}
\caption{Key Holder abort Operation.}
\label{tim:key-holder-abort}
\end{timingdiag}
\begin{timingdiag}
\centering
\begin{tikztimingtable}
clk & [L]11{CC}\\
\color{Red} start & [L]{LL}2{HH}8{LL}\\
\color{Red} opcode & {UU}1{DDDD}{\tiny READ}8{UU}\\
\color{Red} abort & [L]11{LL}\\
\color{Blue}ack & [L]2{LL}{HH}8{LL}\\
\color{Red} valid_in & [L]11{LL}\\
\color{Blue}ready_in & [L]11{LL}\\
\color{Red} data_in & 11{UU}\\
\color{Red} last_word_in & [L]11{LL}\\
\color{Blue}valid_out & [L]3{LL}2{HH}{LL}{HH};[dotted]HH;{HH}2{LL}\\
\color{Red} ready_out & [L]4{LL}{HH}{LL}{HH};[dotted]HH;{HH}2{LL}\\
\color{Blue}data_out & 3{UU}2{DD}{}{UU}{DD{}};[dotted]DD{};{DD}2{UU}\\
\color{Blue}last_word_out & [L]7{LL};[dotted]LL;{HH}2{LL}\\
\color{Blue}decode_error & [L]11{LL}\\
\begin{extracode}
\tableheader{Signal}{Relation}
\fulltablegrid[black!25,ystep=1,xstep=2]
\tablerules
\end{extracode}
\end{tikztimingtable}
\caption{\texttt{READ_KEY_HASH} and \texttt{READ_SERIALIZED_KEY} Key Holder Operation.}
\label{tim:key-holder-read-key-hash}
\end{timingdiag}
\subsection{\acrshort{ROS} Topic}
\label{tim:ros-topic}
\begin{timingdiag}
\centering
\begin{tikztimingtable}
clk & [L]17{CC}\\
\color{Blue}data_available & [L]{LL}14{HH}2{LL}\\
\color{Red} start & [L]2{LL}2{HH}4{LL}{HH}4{LL}{HH}3{LL}\\
\color{Red} opcode & 2{UU}2{DD}{\tiny TAKE}4{UU}1{DD}{\tiny TAKE}4{UU}1{DD}{\tiny TAKE}3{UU}\\
\color{Blue}ack & [L]3{LL}{HH}4{LL}{HH}4{LL}{HH}3{LL}\\
\color{Blue}done & [L]5{LL}{HH}4{LL}{HH}4{LL}{HH}{LL}\\
\color{Blue}return_code & 5{UU}1{DD}{OK}4{UU}1{DD}{OK}4{UU}1{DD}{NOK}{UU}\\
\color{Blue}taken & [L]5{LL}4{HH}{LL}4{HH}3{LL}\\
\color{Blue}{\tiny <TYPENAME_SIGNALS>} & 5{UU}4{DD}{}{UU}4{DD}3{UU}\\
\color{Blue}message_info & 5{UU}4{DD}{}{UU}4{DD}3{UU}\\
\begin{extracode}
\tableheader{Signal}{Relation}
\fulltablegrid[black!25,ystep=1,xstep=2]
\tablerules
\end{extracode}
\end{tikztimingtable}
\caption{\texttt{TAKE} \acrshort{ROS} Subscriber Operation through <MESSAGENAME>_ROS_SUB.}
\label{tim:ros-take}
\end{timingdiag}
\begin{timingdiag}
\centering
\begin{tikztimingtable}
clk & [L]7{CC}\\
\color{Red} start & [L]{LL}2{HH}4{LL}\\
\color{Red} opcode & {UU}2{DD}{\tiny PUBLISH}4{UU}\\
\color{Blue}ack & [L]2{LL}{HH}4{LL}\\
\color{Red} {\tiny <TYPENAME_SIGNALS>} & {UU}5{DD}1{UU}\\
\color{Blue}done & [L]5{LL}{HH}1{LL}\\
\color{Blue}return_code & 5{UU}1{DD}{OK}1{UU}\\
\begin{extracode}
\tableheader{Signal}{Relation}
\fulltablegrid[black!25,ystep=1,xstep=2]
\tablerules
\end{extracode}
\end{tikztimingtable}
\caption{\texttt{PUBLISH} \acrshort{ROS} Publisher Operation through <MESSAGENAME>_ROS_PUB.}
\label{tim:ros-publish}
\end{timingdiag}
\subsection{\acrshort{ROS} Service}
\label{tim:ros-service}
\begin{timingdiag}
\centering
\begin{tikztimingtable}
clk & [L]7{CC}\\
\color{Blue}data_available & 7{UU}\\
\color{Red} start & [L]{LL}2{HH}4{LL}\\
\color{Red} opcode & {UU}2{DD}{\tiny SEND}4{UU}\\
\color{Red} {\tiny <REQUEST_SIGNALS>} & {UU}5{DD}1{UU}\\
\color{Blue}sequence_id & 3{UU}3{DD}1{UU}\\
\color{Blue}ack & [L]2{LL}{HH}4{LL}\\
\color{Blue}done & [L]5{LL}{HH}1{LL}\\
\color{Blue}return_code & 5{UU}1{DD}{OK}1{UU}\\
\color{Blue}taken & [L]7{LL}\\
\color{Blue}{\tiny <RESPONSE_SIGNALS>} & 7{UU}\\
\color{Blue}service_info & 7{UU}\\
\begin{extracode}
\tableheader{Signal}{Relation}
\fulltablegrid[black!25,ystep=1,xstep=2]
\tablerules
\end{extracode}
\end{tikztimingtable}
\caption{\texttt{SEND_REQUEST} \acrshort{ROS} Service Client Operations through <SERVICENAME>_ros_srv_client.}
\label{tim:ros-send-request}
\end{timingdiag}
\begin{timingdiag}
\centering
\begin{tikztimingtable}
clk & [L]17{CC}\\
\color{Blue}data_available & [L]{LL}14{HH}2{LL}\\
\color{Red} start & [L]2{LL}2{HH}4{LL}{HH}4{LL}{HH}3{LL}\\
\color{Red} opcode & 2{UU}2{DD}{\tiny TAKE}4{UU}1{DD}{\tiny TAKE}4{UU}1{DD}{\tiny TAKE}3{UU}\\
\color{Red} {\tiny <REQUEST_SIGNALS>} & 17{UU}\\
\color{Blue}sequence_id & 17{UU}\\
\color{Blue}ack & [L]3{LL}{HH}4{LL}{HH}4{LL}{HH}3{LL}\\
\color{Blue}done & [L]5{LL}{HH}4{LL}{HH}4{LL}{HH}{LL}\\
\color{Blue}return_code & 5{UU}1{DD}{OK}4{UU}1{DD}{OK}4{UU}1{DD}{NOK}{UU}\\
\color{Blue}taken & [L]5{LL}4{HH}{LL}4{HH}3{LL}\\
\color{Blue}{\tiny <RESPONSE_SIGNALS>} & 5{UU}4{DD}{}{UU}4{DD}3{UU}\\
\color{Blue}service_info & 5{UU}4{DD}{}{UU}4{DD}3{UU}\\
\begin{extracode}
\tableheader{Signal}{Relation}
\fulltablegrid[black!25,ystep=1,xstep=2]
\tablerules
\end{extracode}
\end{tikztimingtable}
\caption{\texttt{TAKE_RESPONSE} \acrshort{ROS} Service Client Operations through <SERVICENAME>_ros_srv_client.}
\label{tim:ros-take-response}
\end{timingdiag}
\begin{timingdiag}
\centering
\begin{tikztimingtable}
clk & [L]17{CC}\\
\color{Blue}data_available & [L]{LL}14{HH}2{LL}\\
\color{Red} start & [L]2{LL}2{HH}4{LL}{HH}4{LL}{HH}3{LL}\\
\color{Red} opcode & 2{UU}2{DD}{\tiny TAKE}4{UU}1{DD}{\tiny TAKE}4{UU}1{DD}{\tiny TAKE}3{UU}\\
\color{Red} {\tiny <RESPONSE_SIGNALS>} & 17{UU}\\
\color{Red} request_id & 17{UU}\\
\color{Blue}ack & [L]3{LL}{HH}4{LL}{HH}4{LL}{HH}3{LL}\\
\color{Blue}done & [L]5{LL}{HH}4{LL}{HH}4{LL}{HH}{LL}\\
\color{Blue}return_code & 5{UU}1{DD}{OK}4{UU}1{DD}{OK}4{UU}1{DD}{NOK}{UU}\\
\color{Blue}taken & [L]5{LL}4{HH}{LL}4{HH}3{LL}\\
\color{Blue}{\tiny <REQUEST_SIGNALS>} & 5{UU}4{DD}{}{UU}4{DD}3{UU}\\
\color{Blue}service_info & 5{UU}4{DD}{}{UU}4{DD}3{UU}\\
\begin{extracode}
\tableheader{Signal}{Relation}
\fulltablegrid[black!25,ystep=1,xstep=2]
\tablerules
\end{extracode}
\end{tikztimingtable}
\caption{\texttt{TAKE_REQUEST} \acrshort{ROS} Service Server Operation through <SERVICENAME>_ros_srv_server.}
\label{tim:ros-take-request}
\end{timingdiag}
\begin{timingdiag}
\centering
\begin{tikztimingtable}
clk & [L]7{CC}\\
\color{Blue}data_available & 7{UU}\\
\color{Red} start & [L]{LL}2{HH}4{LL}\\
\color{Red} opcode & {UU}2{DD}{\tiny SEND}4{UU}\\
\color{Red} {\tiny <RESPONSE_SIGNALS>} & {UU}5{DD}1{UU}\\
\color{Red} request_id & {UU}5{DD}1{UU}\\
\color{Blue}ack & [L]2{LL}{HH}4{LL}\\
\color{Blue}done & [L]5{LL}{HH}1{LL}\\
\color{Blue}return_code & 5{UU}1{DD}{OK}1{UU}\\
\color{Blue}taken & [L]7{LL}\\
\color{Blue}{\tiny <REQUEST_SIGNALS>} & 7{UU}\\
\color{Blue}service_info & 7{UU}\\
\begin{extracode}
\tableheader{Signal}{Relation}
\fulltablegrid[black!25,ystep=1,xstep=2]
\tablerules
\end{extracode}
\end{tikztimingtable}
\caption{\texttt{SEND_RESPONSE} \acrshort{ROS} Service Server Operation through <SERVICENAME>_ros_srv_server.}
\label{tim:ros-send-response}
\end{timingdiag}
\subsection{\acrshort{ROS} Action}
\label{tim:ros-action}
\begin{timingdiag}
\centering
\begin{tikztimingtable}
clk & [L]15{CC}\\
\color{Blue}data_available_g & [L]7{LL}6{HH}2{LL}\\
\color{Blue}data_available_r & 15{UU}\\
\color{Blue}data_available_c & 15{UU}\\
\color{Blue}data_available_f & 15{UU}\\
\color{Red} start & [L]{LL}2{HH}4{LL}1{HH}3{LL}1{HH}3{LL}\\
\color{Red} opcode & {UU}2{DD}{\tiny SEND}4{UU}1{DD}{\tiny TAKE}3{UU}1{DD}{\tiny TAKE}3{UU}\\
\color{Blue}ack & [L]2{LL}1{HH}4{LL}1{HH}3{LL}1{HH}3{LL}\\
\color{Blue}done & [L]5{LL}1{HH}3{LL}1{HH}3{LL}1{HH}1{LL}\\
\color{Blue}return_code & 5{UU}1{DD}{OK}3{UU}1{DD}{OK}3{UU}1{DD}{NOK}1{UU}\\
\color{Blue}sequence_id & 3{UU}3{DD}9{UU}\\
\color{Blue}service_info & 9{UU}3{DD}3{UU}\\
\color{Red} goal_id & {UU}5{DD}9{UU}\\
\color{Red} {\tiny <GOAL_SIGNALS>} & {UU}5{DD}9{UU}\\
\color{Blue}goal_accepted & 9{UU}3{DD}3{UU}\\
\color{Blue}goal_stamp & 9{UU}3{DD}3{UU}\\
\color{Red} result_goal_id & 15{UU}\\
\color{Blue}{\tiny <RESULT_SIGNALS>} & 15{UU}\\
\color{Blue}result_status & 15{UU}\\
\color{Red} cancel_goal_id & 15{UU}\\
\color{Red} cancel_stamp & 15{UU}\\
\color{Blue}cancel_return_code & 15{UU}\\
\color{Blue}cancel_goals_canceling_* & 15{UU}\\
\color{Blue}feedback_goal_id & 15{UU}\\
\color{Blue}{\tiny <FEEDBACK_SIGNALS>} & 15{UU}\\
\begin{extracode}
\tableheader{Signal}{Relation}
\fulltablegrid[black!25,ystep=1,xstep=2]
\tablerules
\end{extracode}
\end{tikztimingtable}
\caption{\texttt{SEND_GOAL_REQUEST} and \texttt{TAKE_GOAL_REQUEST} \acrshort{ROS} Action Client Operations through <ACTIONNAME>_ros_action_client.}
\label{tim:ros-action-client-goal}
\end{timingdiag}
\begin{timingdiag}
\centering
\begin{tikztimingtable}
clk & [L]15{CC}\\
\color{Blue}data_available_g & 15{UU}\\
\color{Blue}data_available_r & [L]7{LL}6{HH}2{LL}\\
\color{Blue}data_available_c & 15{UU}\\
\color{Blue}data_available_f & 15{UU}\\
\color{Red} start & [L]{LL}2{HH}4{LL}1{HH}3{LL}1{HH}3{LL}\\
\color{Red} opcode & {UU}2{DD}{\tiny SEND}4{UU}1{DD}{\tiny TAKE}3{UU}1{DD}{\tiny TAKE}3{UU}\\
\color{Blue}ack & [L]2{LL}1{HH}4{LL}1{HH}3{LL}1{HH}3{LL}\\
\color{Blue}done & [L]5{LL}1{HH}3{LL}1{HH}3{LL}1{HH}1{LL}\\
\color{Blue}return_code & 5{UU}1{DD}{OK}3{UU}1{DD}{OK}3{UU}1{DD}{NOK}1{UU}\\
\color{Blue}sequence_id & 3{UU}3{DD}9{UU}\\
\color{Blue}service_info & 9{UU}3{DD}3{UU}\\
\color{Red} goal_id & 15{UU}\\
\color{Red} {\tiny <GOAL_SIGNALS>} & 15{UU}\\
\color{Blue}goal_accepted & 15{UU}\\
\color{Blue}goal_stamp & 15{UU}\\
\color{Red} result_goal_id & {UU}5{DD}9{UU}\\
\color{Blue}{\tiny <RESULT_SIGNALS>} & 9{UU}3{DD}3{UU}\\
\color{Blue}result_status & 9{UU}3{DD}3{UU}\\
\color{Red} cancel_goal_id & 15{UU}\\
\color{Red} cancel_stamp & 15{UU}\\
\color{Blue}cancel_return_code & 15{UU}\\
\color{Blue}cancel_goals_canceling_* & 15{UU}\\
\color{Blue}feedback_goal_id & 15{UU}\\
\color{Blue}{\tiny <FEEDBACK_SIGNALS>} & 15{UU}\\
\begin{extracode}
\tableheader{Signal}{Relation}
\fulltablegrid[black!25,ystep=1,xstep=2]
\tablerules
\end{extracode}
\end{tikztimingtable}
\caption{\texttt{SEND_RESULT_REQUEST} and \texttt{TAKE_RESULT_REQUEST} \acrshort{ROS} Action Client Operations through <ACTIONNAME>_ros_action_client.}
\label{tim:ros-action-client-result}
\end{timingdiag}
\begin{timingdiag}
\centering
\begin{tikztimingtable}
clk & [L]15{CC}\\
\color{Blue}data_available_g & 15{UU}\\
\color{Blue}data_available_r & 15{UU}\\
\color{Blue}data_available_c & [L]7{LL}6{HH}2{LL}\\
\color{Blue}data_available_f & 15{UU}\\
\color{Red} start & [L]{LL}2{HH}4{LL}1{HH}3{LL}1{HH}3{LL}\\
\color{Red} opcode & {UU}2{DD}{\tiny SEND}4{UU}1{DD}{\tiny TAKE}3{UU}1{DD}{\tiny TAKE}3{UU}\\
\color{Blue}ack & [L]2{LL}1{HH}4{LL}1{HH}3{LL}1{HH}3{LL}\\
\color{Blue}done & [L]5{LL}1{HH}3{LL}1{HH}3{LL}1{HH}1{LL}\\
\color{Blue}return_code & 5{UU}1{DD}{OK}3{UU}1{DD}{OK}3{UU}1{DD}{NOK}1{UU}\\
\color{Blue}sequence_id & 3{UU}3{DD}9{UU}\\
\color{Blue}service_info & 9{UU}3{DD}3{UU}\\
\color{Red} goal_id & 15{UU}\\
\color{Red} {\tiny <GOAL_SIGNALS>} & 15{UU}\\
\color{Blue}goal_accepted & 15{UU}\\
\color{Blue}goal_stamp & 15{UU}\\
\color{Red} result_goal_id & 15{UU}\\
\color{Blue}{\tiny <RESULT_SIGNALS>} & 15{UU}\\
\color{Blue}result_status & 15{UU}\\
\color{Red} cancel_goal_id & {UU}5{DD}9{UU}\\
\color{Red} cancel_stamp & {UU}5{DD}9{UU}\\
\color{Blue}cancel_return_code & 9{UU}3{DD}3{UU}\\
\color{Blue}cancel_goals_canceling_* & 9{UU}3{DD}3{UU}\\
\color{Blue}feedback_goal_id & 15{UU}\\
\color{Blue}{\tiny <FEEDBACK_SIGNALS>} & 15{UU}\\
\begin{extracode}
\tableheader{Signal}{Relation}
\fulltablegrid[black!25,ystep=1,xstep=2]
\tablerules
\end{extracode}
\end{tikztimingtable}
\caption{\texttt{SEND_CANCEL_REQUEST} and \texttt{TAKE_CANCEL_REQUEST} \acrshort{ROS} Action Client Operations through <ACTIONNAME>_ros_action_client.}
\label{tim:ros-action-client-cancel}
\end{timingdiag}
\begin{timingdiag}
\centering
\begin{tikztimingtable}
clk & [L]10{CC}\\
\color{Blue}data_available_g & 10{UU}\\
\color{Blue}data_available_r & 10{UU}\\
\color{Blue}data_available_c & 10{UU}\\
\color{Blue}data_available_f & [L]1{LL}7{HH}2{LL}\\
\color{Red} start & [L]1{LL}2{HH}4{LL}1{HH}2{LL}\\
\color{Red} opcode & 1{UU}2{DD}{\tiny TAKE}4{UU}1{DD}{\tiny TAKE}2{UU}\\
\color{Blue}ack & [L]2{LL}1{HH}4{LL}1{HH}2{LL}\\
\color{Blue}done & [L]4{LL}1{HH}3{LL}1{HH}1{LL}\\
\color{Blue}return_code & 4{UU}1{DD}{OK}3{UU}1{DD}{NOK}1{UU}\\
\color{Blue}sequence_id & 10{UU}\\
\color{Blue}service_info & 10{UU}\\
\color{Red} goal_id & 10{UU}\\
\color{Red} {\tiny <GOAL_SIGNALS>} & 10{UU}\\
\color{Blue}goal_accepted & 10{UU}\\
\color{Blue}goal_stamp & 10{UU}\\
\color{Red} result_goal_id & 10{UU}\\
\color{Blue}{\tiny <RESULT_SIGNALS>} & 10{UU}\\
\color{Blue}result_status & 10{UU}\\
\color{Red} cancel_goal_id & 10{UU}\\
\color{Red} cancel_stamp & 10{UU}\\
\color{Blue}cancel_return_code & 10{UU}\\
\color{Blue}cancel_goals_canceling_* & 10{UU}\\
\color{Blue}feedback_goal_id & 4{UU}4{DD}2{UU}\\
\color{Blue}{\tiny <FEEDBACK_SIGNALS>} & 4{UU}4{DD}2{UU}\\
\begin{extracode}
\tableheader{Signal}{Relation}
\fulltablegrid[black!25,ystep=1,xstep=2]
\tablerules
\end{extracode}
\end{tikztimingtable}
\caption{\texttt{TAKE_FEEDBACK} \acrshort{ROS} Action Client Operations through <ACTIONNAME>_ros_action_client.}
\label{tim:ros-action-client-feedback}
\end{timingdiag}
\begin{timingdiag}
\centering
\begin{tikztimingtable}
clk & [L]7{CC}\\
\color{Red} start & [L]7{LL}\\
\color{Red} opcode & 7{UU}\\
\color{Red} goal_handle_in & 7{UU}\\
\color{Red} goal_state_in & 7{UU}\\
\color{Blue}ack & [L]7{LL}\\
\color{Blue}done & [L]7{LL}\\
\color{Blue}return_code & 7{UU}\\
\color{Blue}goal_handle_out & 7{UU}\\
\color{Blue}goal_state_out & 7{UU}\\
\color{Blue}goal_id & 7{UU}\\
\color{Blue}goal_result_index & 7{UU}\\
\color{Blue}goal_stamp & 7{UU}\\
\color{Blue}new_goal_request & [L]1{LL}2{HH}4{LL}\\
\color{Blue}new_goal_handle & 1{UU}2{DD}4{UU}\\
\color{Blue}new_goal_result_index & 1{UU}2{DD}4{UU}\\
\color{Blue}{\tiny <GOAL_SIGNALS>} & 1{UU}2{DD}4{UU}\\
\color{Red} new_goal_accepted & 2{UU}1{DD}4{UU}\\
\color{Red} new_goal_response & [L]2{LL}1{HH}4{LL}\\
\color{Blue}cancel_request & [L]4{LL}2{HH}1{LL}\\
\color{Blue}cancel_request_handle & 4{UU}2{DD}1{UU}\\
\color{Red} cancel_accepted & 5{UU}1{DD}1{UU}\\
\color{Red} cancel_response & [L]5{LL}1{HH}1{LL}\\
\color{Red} {\tiny <RESULT_SIGNALS>} & 7{UU}\\
\color{Red} {\tiny <FEEDBACK_SIGNALS>} & 7{UU}\\
\begin{extracode}
\tableheader{Signal}{Relation}
\fulltablegrid[black!25,ystep=1,xstep=2]
\tablerules
\end{extracode}
\end{tikztimingtable}
\caption{Accept/Reject Goal/Cancel Requests through <ACTIONNAME>_ros_action_server.}
\label{tim:ros-action-server-user}
\end{timingdiag}
\begin{timingdiag}
\centering
\begin{tikztimingtable}
clk & [L]6{CC}\\
\color{Red} start & [L]1{LL}2{HH}3{LL}\\
\color{Red} opcode & 1{UU}2{DD}3{UU}\\
\color{Red} goal_handle_in & 6{UU}\\
\color{Red} goal_state_in & 6{UU}\\
\color{Blue}ack & [L]2{LL}1{HH}3{LL}\\
\color{Blue}done & [L]4{LL}1{HH}1{LL}\\
\color{Blue}return_code & 4{UU}1{DD}{OK}1{UU}\\
\color{Blue}goal_handle_out & 4{UU}1{DD}1{UU}\\
\color{Blue}goal_state_out & 4{UU}1{DD}1{UU}\\
\color{Blue}goal_id & 4{UU}1{DD}1{UU}\\
\color{Blue}goal_result_index & 4{UU}1{DD}1{UU}\\
\color{Blue}goal_stamp & 4{UU}1{DD}1{UU}\\
\color{Blue}new_goal_request & [L]6{LL}\\
\color{Blue}new_goal_handle & 6{UU}\\
\color{Blue}new_goal_result_index & 6{UU}\\
\color{Blue}{\tiny <GOAL_SIGNALS>} & 6{UU}\\
\color{Red} new_goal_accepted & 6{UU}\\
\color{Red} new_goal_response & [L]6{LL}\\
\color{Blue}cancel_request & [L]6{LL}\\
\color{Blue}cancel_request_handle & 6{UU}\\
\color{Red} cancel_accepted & 6{UU}\\
\color{Red} cancel_response & [L]6{LL}\\
\color{Red} {\tiny <RESULT_SIGNALS>} & 6{UU}\\
\color{Red} {\tiny <FEEDBACK_SIGNALS>} & 6{UU}\\
\begin{extracode}
\tableheader{Signal}{Relation}
\fulltablegrid[black!25,ystep=1,xstep=2]
\tablerules
\end{extracode}
\end{tikztimingtable}
\caption{\texttt{GET_FIRST_GOAL} and \texttt{GET_LAST_GOAL} \acrshort{ROS} Action Server Operations through <ACTIONNAME>_ros_action_server.}
\label{tim:ros-action-server-get-first-goal}
\end{timingdiag}
\begin{timingdiag}
\centering
\begin{tikztimingtable}
clk & [L]6{CC}\\
\color{Red} start & [L]1{LL}2{HH}3{LL}\\
\color{Red} opcode & 1{UU}2{DD}3{UU}\\
\color{Red} goal_handle_in & 1{UU}2{DD}3{UU}\\
\color{Red} goal_state_in & 6{UU}\\
\color{Blue}ack & [L]2{LL}1{HH}3{LL}\\
\color{Blue}done & [L]4{LL}1{HH}1{LL}\\
\color{Blue}return_code & 4{UU}1{DD}{OK}1{UU}\\
\color{Blue}goal_handle_out & 4{UU}1{DD}1{UU}\\
\color{Blue}goal_state_out & 4{UU}1{DD}1{UU}\\
\color{Blue}goal_id & 4{UU}1{DD}1{UU}\\
\color{Blue}goal_result_index & 4{UU}1{DD}1{UU}\\
\color{Blue}goal_stamp & 4{UU}1{DD}1{UU}\\
\color{Blue}new_goal_request & [L]6{LL}\\
\color{Blue}new_goal_handle & 6{UU}\\
\color{Blue}new_goal_result_index & 6{UU}\\
\color{Blue}{\tiny <GOAL_SIGNALS>} & 6{UU}\\
\color{Red} new_goal_accepted & 6{UU}\\
\color{Red} new_goal_response & [L]6{LL}\\
\color{Blue}cancel_request & [L]6{LL}\\
\color{Blue}cancel_request_handle & 6{UU}\\
\color{Red} cancel_accepted & 6{UU}\\
\color{Red} cancel_response & [L]6{LL}\\
\color{Red} {\tiny <RESULT_SIGNALS>} & 6{UU}\\
\color{Red} {\tiny <FEEDBACK_SIGNALS>} & 6{UU}\\
\begin{extracode}
\tableheader{Signal}{Relation}
\fulltablegrid[black!25,ystep=1,xstep=2]
\tablerules
\end{extracode}
\end{tikztimingtable}
\caption{\texttt{GET_GOAL}, \texttt{GET_NEXT_GOAL}, and \texttt{GET_PREVIOUS_GOAL} \acrshort{ROS} Action Server Operations through <ACTIONNAME>_ros_action_server.}
\label{tim:ros-action-server-get-goal}
\end{timingdiag}
\begin{timingdiag}
\centering
\begin{tikztimingtable}
clk & [L]6{CC}\\
\color{Red} start & [L]1{LL}2{HH}3{LL}\\
\color{Red} opcode & 1{UU}2{DD}3{UU}\\
\color{Red} goal_handle_in & 1{UU}2{DD}3{UU}\\
\color{Red} goal_state_in & 1{UU}2{DD}3{UU}\\
\color{Blue}ack & [L]2{LL}1{HH}3{LL}\\
\color{Blue}done & [L]4{LL}1{HH}1{LL}\\
\color{Blue}return_code & 4{UU}1{DD}{OK}1{UU}\\
\color{Blue}goal_handle_out & 6{UU}\\
\color{Blue}goal_state_out & 6{UU}\\
\color{Blue}goal_id & 6{UU}\\
\color{Blue}goal_result_index & 6{UU}\\
\color{Blue}goal_stamp & 6{UU}\\
\color{Blue}new_goal_request & [L]6{LL}\\
\color{Blue}new_goal_handle & 6{UU}\\
\color{Blue}new_goal_result_index & 6{UU}\\
\color{Blue}{\tiny <GOAL_SIGNALS>} & 6{UU}\\
\color{Red} new_goal_accepted & 6{UU}\\
\color{Red} new_goal_response & [L]6{LL}\\
\color{Blue}cancel_request & [L]6{LL}\\
\color{Blue}cancel_request_handle & 6{UU}\\
\color{Red} cancel_accepted & 6{UU}\\
\color{Red} cancel_response & [L]6{LL}\\
\color{Red} {\tiny <RESULT_SIGNALS>} & 6{UU}\\
\color{Red} {\tiny <FEEDBACK_SIGNALS>} & 6{UU}\\
\begin{extracode}
\tableheader{Signal}{Relation}
\fulltablegrid[black!25,ystep=1,xstep=2]
\tablerules
\end{extracode}
\end{tikztimingtable}
\caption{\texttt{UPDATE_GOAL_STATE} \acrshort{ROS} Action Server Operations through <ACTIONNAME>_ros_action_server.}
\label{tim:ros-action-server-update-goal-state}
\end{timingdiag}
\begin{timingdiag}
\centering
\begin{tikztimingtable}
clk & [L]6{CC}\\
\color{Red} start & [L]1{LL}2{HH}3{LL}\\
\color{Red} opcode & 1{UU}2{DD}3{UU}\\
\color{Red} goal_handle_in & 1{UU}2{DD}3{UU}\\
\color{Red} goal_state_in & 6{UU}\\
\color{Blue}ack & [L]2{LL}1{HH}3{LL}\\
\color{Blue}done & [L]4{LL}1{HH}1{LL}\\
\color{Blue}return_code & 4{UU}1{DD}{OK}1{UU}\\
\color{Blue}goal_handle_out & 6{UU}\\
\color{Blue}goal_state_out & 6{UU}\\
\color{Blue}goal_id & 6{UU}\\
\color{Blue}goal_result_index & 6{UU}\\
\color{Blue}goal_stamp & 6{UU}\\
\color{Blue}new_goal_request & [L]6{LL}\\
\color{Blue}new_goal_handle & 6{UU}\\
\color{Blue}new_goal_result_index & 6{UU}\\
\color{Blue}{\tiny <GOAL_SIGNALS>} & 6{UU}\\
\color{Red} new_goal_accepted & 6{UU}\\
\color{Red} new_goal_response & [L]6{LL}\\
\color{Blue}cancel_request & [L]6{LL}\\
\color{Blue}cancel_request_handle & 6{UU}\\
\color{Red} cancel_accepted & 6{UU}\\
\color{Red} cancel_response & [L]6{LL}\\
\color{Red} {\tiny <RESULT_SIGNALS>} & 6{UU}\\
\color{Red} {\tiny <FEEDBACK_SIGNALS>} & 1{UU}4{DD}1{UU}\\
\begin{extracode}
\tableheader{Signal}{Relation}
\fulltablegrid[black!25,ystep=1,xstep=2]
\tablerules
\end{extracode}
\end{tikztimingtable}
\caption{\texttt{PUBLISH_FEEDBACK} \acrshort{ROS} Action Server Operations through <ACTIONNAME>_ros_action_server.}
\label{tim:ros-action-server-publish-feedback}
\end{timingdiag}
\end{document}
Reference in New Issue View Git Blame Copy Permalink