git-svn-id: svn+ssh://mecka.net/home/svn/rtcorba-paper@12 da047780-0f9f-48de-953f-cd541ee48bbd

1 files changed, 42 insertions, 18 deletions

diff --git a/paper.tex b/paper.tex
index 3438b54..47f83c1 100755
--- a/paper.tex
+++ b/paper.tex
@@ -118,21 +118,23 @@ Automation technology lacks an established platform independent, high-level, obj
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

 \section{Introduction}

 

-Currently communication in automation is mainly realized with a huge number of different fieldbuses. However since 2005 there is an increasing trend, for using ethernet based communication methods. Another trend is, using PCs and software for simulating PLCs. But why not combine these two trends, to control machines in real-time with object-orientated middleware? The infrastructure is already given\dots

+Currently communication in automation is mainly realized with a huge number of different fieldbuses. However since 2005 there is an increasing trend, for using ethernet based communication methods. Another trend is, using PCs, real-time operating systems and software for controlling machines. But why not combine these two trends, controlling machines in real-time over an object-orientated middleware? The efforts would be: faster development cycles, easier maintaining and extending of the software modules\dots 

+

+And with ACE/TAO a Real-Time CORBA Implementation and the RT\_PREEMPT patch, the infrastructure for doing this with Linux, is already given!

 

 \subsection{CORBA}

 CORBA is a Middleware, which allows RPC\footnote{Remote Procedure Call}-based IPC\footnote{Inter Process Communication} between different operating systems and different programming languages (Figure 1).

 \epsin{orb}{80}{fig1:f1}{CORBA Architecture}

 The communication interfaces are defined in IDL\footnote{Interface Definition Language}. The IDL files are compiled into, e.g. c++, java, \dots, code which does the (de)serialization of the datatypes. The interface implementations (CORBA objects) are registered at language specific ORB\footnote{Object Request Broker}s. Each CORBA process owns one ORB, which handles the function requests and returns the calculated values.

 

-\subsection{real-time CORBA}

-\epsin{rtcorbaext}{70}{fig1:f2}{Real-time CORBA}

+\subsection{Real-Time CORBA}

+\epsin{rtcorbaext}{70}{fig1:f2}{Real-time CORBA \\(source: [1])}

 As shown in figure 2, a real-time capable ORB extends a standard ORB with the following features: locating objects in constant time, preallocation of resources, operating system independent priority handling, priority based scheduling.

 

 \subsection{ACE/TAO}

-ACE is an open-source c++ framework for platform-independent system- and network-programming. TAO is a real-time CORBA implementation build on top of ACE (Figure 3).

+ACE is an open-source c++ framework for platform-independent system- and network-programming. TAO is a Real-Time CORBA implementation build on top of ACE (Figure 3).

 

-\epsin{ace}{80}{fig1:f3}{ACE/TAO framework}

+\epsin{ace}{80}{fig1:f3}{ACE/TAO framework \\(source: [2])}

 

 The ACE/TAO package is available for all important operating systems. The hole framework is trimmed for embedded systems: Each application described in this paper consumes less than 1 MByte of RAM. Also the consumed CPU time is suprisingly low.

 

@@ -161,46 +163,68 @@ module benchmark{
 

 The \textit{Port} function is called by the \textit{sender} as soon as the state of one of its digital inputs changes. The real end to end latency is meassured with the oscilloscope.

 

-To simulate the transmission of bigger process data images, the parameter \textit{in string data} is read in from a text file, so his length, could be changed after compile time, by editing the text file.

-

 \epsin{sequenzV1}{80}{fig1:f5}{RPC measurement: sequence diagramm}

 

+Figure 6a shows a histogramm over the latency, a process data image, including \textit{portNo} and \textit{value} (the \textit{data} string has length 0), needs from the digital input of the supplier system to the digital output of receiver system I. These results are measured on a RT\_PREEMPT enabled kernel, during heavy disk i/o, network traffic on none priorized NICs and 5 low priorized CPU burners running.

+

+\epsin{v1Last}{80}{fig1:f6a}{Latency histogramm RT\_PREEMPT, system load}

+

+\epsin{vanilla-ohne-last}{80}{fig1:f6b}{Latency histogramm Vanilla, without system load}

+

+The results of the same measurement on a none RT\_PREEMPT enabled kernel are shown in figure 6b (without system load) and 6c.

+

+\epsin{vanilla-mit-last}{80}{fig1:f6c}{Latency histogramm Vanilla, system load}

+

+Basicly the same measurement under identical system load, was made once again. Only change: Both receiving systems are used. Receiving system I hosts the object for setting port values, with lower priorization, than receiving system II. On the supplier system, the rightangle waveform is connected with two digital input ports. Changes on one port are commited two the higher priorized \textit{receiver} on system II; changes on the other port are sent to the lower priorized receiving system I. Figure 7 shows, that no priority inversion occours.

+

+\epsin{v3Last}{80}{fig1:f7}{Latency histogramm, two priorizations}

+

+To simulate the transmission of bigger process data images, the parameter \textit{in string data} is read in from a text file, so his length, could be changed after compile time, by editing the text file. Figure 8 shows, the bigger the process data image, the bigger the difference between immediate and worst case.

+

+\epsin{v4plot}{80}{fig1:f8}{dependency between process data image siye and latency}

+

 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

 %% SUB SECTION (OPTIONAL)

 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

-\subsection{TAO real-time Event-Channel}

+\subsection{TAO Real-Time Event-Channel}

 

-The TAO real-time Event-Channel is a CORBA Messaging Service. Suppliers are sending messages to the Messaging Service. A client can subscribe for messages at the Messaging Service.

+The TAO Real-Time Event-Channel is a Messaging Service. Suppliers are sending messages to the Messaging Service. A client can subscribe for messages at the Messaging Service.

 

 As soon as the value of the digital input of the Supplier changes, the new value of the digital input port is send to the Messaging Service. The Messaging Service sends this value, to all subscribed clients. A client writes the values from the messages, to their digital output.

 

-\epsin{sequenzV2}{80}{fig1:f6}{Event-Channel measurement: sequence diagramm}

+\epsin{sequenzV2}{80}{fig1:f9}{Event-Channel measurement: sequence diagramm}

+

+In case, the TAO Real-Time Event-Channel is a CORBA application working between Receiver and Supplier, the latency should be approximately two times the latency of the 1:1 RPC measurement. Figure 10 shows, that this is a correct assumption.

+

+\epsin{v2Last}{80}{fig1:f10}{Latency histogramm, TAO RT Event-Channel}

 

 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

 %% NEXT SECTION (OPTIONAL)

 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

 \section{Needed operating system functionalities}

 

-An TAO ORB can only schedule its CORBA requests correctly, if the underlying operating system has an priorization based scheduler, with a defined maximum scheduling latency. The timer and scheduling latency of a linux system can be determined with cyclictest. For example, the worst case latency on a RT\_PREEMPT enabled box is $26 \mu s$. The same test, on the same box, but with RT\_PREEMPT disabled is $39.6 ms$.

+A TAO ORB can only schedule its CORBA requests correctly, if the underlying operating system has an priorization based scheduler, with a defined maximum scheduling latency. The timer and scheduling latency of a Linux system can be determined with cyclictest. For example, the worst case latency on a RT\_PREEMPT enabled box is $26 \mu s$. The same test, on the same box, but with RT\_PREEMPT disabled is $39.6 ms$.

 

-The operating system should support priorization of device i/o data. The real-time application must not beeing interrupted by incomming traffic on any device, excepted data the real-time application must react on (e.g. digital inputs). On a RT\_PREEMPT enabled linux, the most part of all ISR\footnote{interrupt service routine}s are done in kernel threads, which can be priorized from userspace. This solution has two little cons: IRQ sharing and the softirqs for networking. IRQ sharing prevents from a real per device priorization. The softirqs for networking handle the traffic of all NICs in the system. So the priorization of network data from a specific device is not possible. But in case real-time networking gets more and more important, the community works on a solution for this issue.

+The operating system should support priorization of device i/o data. The real-time application must not beeing interrupted by incomming traffic on any device, excepted data the real-time application must react on (e.g. digital inputs). On a RT\_PREEMPT enabled Linux, the most part of all ISR\footnote{interrupt service routine}s are done in kernel threads, which can be priorized from userspace. This solution has two little cons: IRQ sharing and the softirqs for networking. IRQ sharing prevents from a real per device priorization. The softirqs for networking handle the traffic of all NICs in the same thread. So the priorization of network data from a specific device is not possible. But in case real-time networking gets more and more important, the community works on a solution for this issue.

 

 Not all NICs (especially their firmware and driver) are good for real-time networking. Many modern NICs don't request an interrupt for each received package. They only request an interrupt if a defined amount of data is received, or a defined timeout is over. Esspecially for real-time network communications with little data transfer, these cards causes high latencies.

 

 \section{Conclusion}

 

-Using an object-orientated middleware for real-time communication over standard ethernet hardware, is especially in the automation industrie, not a trivial thing. But with ACE/TAO and RT\_PREEMPT enabled Linux it is no longer science-fiction.

+The pros of an object-orientated middleware is, that the applications can be easily extended, also debugging is much more easier, than working with bits and bytes on sockets. A further effort is, that the hole connection handling is done by the middleware.

+

+This paper shows, that using an object-orientated middleware for real-time communication over standard ethernet hardware, is especially in the automation industrie, not a trivial thing. But with ACE/TAO and RT\_PREEMPT enabled Linux it is no longer science-fiction.

+

+[3] is a good resource for further informations.

 

 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

 %% REFERNCES (REQUIRED)

 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

 \begin{thebibliography}{9}%use this if you have <=9 bib refs

 %\begin{thebibliography}{99}%use this if you have >9 bib refs

-\bibitem{book1},{\it PCI 9656BA Data Book Version 1.0},2003, PLX Technology, Inc.

-\bibitem {book2},{\it RTLinux3.1 Getting Started with RTLinux},2001, {\sc FSM Labs, Inc.}

-\bibitem {paper1},{\it Advanced filesystem implementer¡¯s guide, introducing XFS}, Daniel Robbins,01 Jan 2002,{\sc Gentoo Technologies£¬Inc.}

-\bibitem {paper2},{\it http://www.realtimelinuxfoundation.org/home.html}

-\bibitem {paper3},{\it http://compreviews.about.com/od/storage/l/aaRAIDPage1.htm}

+\bibitem{paper1},{\it Real-time CORBA Specification},2005, {\sc OMG}

+\bibitem{paper2},{\it Overview of ACE},2007\\{\it http://www.cs.wustl.edu/schmidt/ACE-overview.html}

+\bibitem{paper3},{\it TAO technical documents},2007\\{\it http://www.cs.wustl.edu/schmidt/corba-research-realtime.html}

 \end{thebibliography}

 

 \end{multicols}