RTI: patents on NDDS/RTPS?

H

Thread Starter

Harald Albrecht

Having visited a workshop on "Ethernet and TCP/IP in Industrial Automation" a simple question popped up during questionaire time:

Does anybody know whether Real Time Innovations has any patents on their NDDS realtime publisher-subscriber system? Are there any patents on their protocol?

I'm asking because the guy from RTI could not answer these questions -- he told the audience that he did not know whether there are patents or no patents on NDDS and the RTPS protocol. Well, that's probably one of the few university spin-offs in the US with a business model not protected by own patents...

Funny was part of the presentation where the guy from RTI talked about RTPS becoming an IETF RFC. After someone asked for details he admitted, that there are several kinds of RFC classes, so RTPS is intended to become an "informationional RFC"--he probably meant a FYI RFC (for your information RFC)...

Ahhh, and then the audience had fun watching PROFInet and iDA eyeing each other carefully and outdoing each other in terms of access latencies around the milliseconds border. And we had even
more fun several times hearing how "company x" grants "initiative y" use of their patented technology. So what happens if someone is not a member of y but does use the software provided by y? So let's see whether the sky will fall and all the automation beasts will overcome us...

Still hoping and waiting for the FAF -- the Free Automation Foundation,
Harald

--
Harald Albrecht
Chair of Process Control Engineering
RWTH Aachen University of Technology
Turmstrasse 46, D-52064 Aachen, Germany
Tel.: +49 241 80-7703, Fax: +49 241 8888-238

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
R

Robert Schwebel

Hi Harald and list,

On Tue, 10 Jul 2001, Harald Albrecht wrote:
> Does anybody know whether Real Time Innovations has any patents on
> their NDDS realtime publisher-subscriber system? Are there any patents
> on their protocol?

We yesterday had a very interesting discussion on the SPS/IPC/Drives trade show in Nuernberg with two guys from RTI at the IDA booth. In result, I now have a CD containing the specification of the RTPS 1.0 protocol ontop of UDP...

I've directly asked for their strategy regarding the IETF standardisation ("it is on progress and will definitely happen") and especially about the possibility of a free implementation for Linux. It was a little bit funny ("you don't have to implement the stack yourself, just buy it from us"), but in the end they don't seem to have objections about a free implementation, at least that's what the CEO of the German RTC bureau told me.

Some interesting facts came out from the discussion:

- Realtime Ethernet is just a buzzword. It won't be possible to have hard
realtime on Ethernet. All attempts are soft RT with a very low error
probability.

- RTI implements their protocols ontop of the native network stacks of
Windows and QNX, that means that they have realtime performance only in
the application -> after the packet has traversed the whole stack.

- RTI did not make measurements yet regarding the question if their
assumptions (poisson distribution of incoming packets) are correct and
what will happen in such a network in case of message storms.

- All companies seem to rely on the fact that a 100 MBit network will
never exceed 20-30% load.

Comments are welcome...

Robert
--
+--------------------------------------------------------+
| Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de |
| Pengutronix - Linux Solutions for Science and Industry |
| Braunschweiger Straße 79, 31134 Hildesheim, Germany |
| Phone: +49-5121-28619-0 | Fax: +49-5121-28619-4 |
+--------------------------------------------------------+

_______________________________________________
LinuxPLC mailing list
[email protected] http://lists.linuxplc.org/mailman/listinfo/linuxplc

 
H

Harald Albrecht

Robert Schwebel wrote:

> I've directly asked for their strategy regarding the IETF
> standardisation ("it is on progress and will definitely happen")

I talked to one of RTI's representatives during a meeting in Magdeburg several weeks ago and he told me that they only aim at an
"informational" RFC (remember, there are different kinds of RFC, so not all RFCs are created equal). "Honi soi qui mal y ponse."

> and especially about the
> possibility of a free implementation for Linux. It was a little bit
> funny ("you don't have to implement the stack yourself, just buy it
> from us"), but in the end they don't seem to have objections about a
> free implementation, at least that's what the CEO of the German RTC
> bureau told me.

Did he *explicitly mention* that there are no patent issues for RTI?

> - RTI implements their protocols ontop of the native network stacks of
> Windows and QNX, that means that they have realtime performance only in
> the application -> after the packet has traversed the whole stack.

As I already mentioned in a private email to Robert, ifak Magdeburg is working on this issue and aims at establishing a QoS-related socket API
extension, so both the operating system as well as the network driver (and even the NIC) can try to achieve their best with respect to deadlines. We have to see how this will turn out in the end. I wish them the very best.

> - RTI did not make measurements yet regarding the question if their
> assumptions (poisson distribution of incoming packets) are correct and
> what will happen in such a network in case of message storms.
>
> - All companies seem to rely on the fact that a 100 MBit network will
> never exceed 20-30% load.

Both issues are probably very closely related. Especially I'm currently not aware of any public statistical model taking higher load, self-similiarity and switching into proper consideration. If someone on the list does know more about better models, could she please give a hint?

Robert, thank you very much for the detailed and interesting information. Curt, this is now probably your turn ;)

Harald

--
Harald Albrecht
Chair of Process Control Engineering
RWTH Aachen University of Technology
Turmstrasse 46, D-52064 Aachen, Germany
Tel.: +49 241 80-97703, Fax: +49 241 80-92238

_______________________________________________
LinuxPLC mailing list
[email protected] http://lists.linuxplc.org/mailman/listinfo/linuxplc

 
C

Curt Wuollet

Hi Robert

Interesting stuff, I was digging through the sites to figure out how it all goes together.
While RT Ethernet is a buzzword, it's a little known fact that the alternatives are far from perfect as well.

Questions for those more familiar than I:

I get the high level interface part, no network programming.

What I haven't been able to discover is what makes publish/subscribe desirable enough to justify the complexity on small machines. I have complete systems that run less software than these protocols.

It's probably my ignorance but it seems like an odd way to talk to I/O. Where does the middleware live? The ORB? How would I use it in a typical automation cell?

What makes it a good thing for Mat/LPLC and automation in general? It seems like a better fit for client server apps.

I think I've missed something along the way, I'm confused

Regards

cww

--
Free Tools!
Machine Automation Tools (LinuxPLC) Free, Truly Open & Publicly Owned Industrial Automation Software For Linux. mat.sourceforge.net.
Day Job: Heartland Engineering, Automation & ATE for Automotive Rebuilders.
Consultancy: Wide Open Technologies: Moving Business & Automation to Linux. _______________________________________________
LinuxPLC mailing list
[email protected] http://lists.linuxplc.org/mailman/listinfo/linuxplc

 
C

Curt Wuollet

Hi Harald.

This one kinda snuck up on me. I'm still trying to figure out what all the excitement is about. I posted some questions on the general topic in response to Robert's post. I'm sure I'm not the only one who could use the answers ;^) This email is an RFC, for what that's worth. Perhaps you university types can illuminate?

Regards.

cww

--
Free Tools!
Machine Automation Tools (LinuxPLC) Free, Truly Open & Publicly Owned Industrial Automation Software For Linux. mat.sourceforge.net.
Day Job: Heartland Engineering, Automation & ATE for Automotive Rebuilders.
Consultancy: Wide Open Technologies: Moving Business & Automation to Linux. _______________________________________________
LinuxPLC mailing list
[email protected] http://lists.linuxplc.org/mailman/listinfo/linuxplc
 
R

Robert Schwebel

On Fri, 30 Nov 2001, Harald Albrecht wrote:
> I talked to one of RTI's representatives during a meeting in Magdeburg
> several weeks ago and he told me that they only aim at an
> "informational" RFC (remember, there are different kinds of RFC, so
> not all RFCs are created equal). "Honi soi qui mal y ponse."

I asked him directly what an "informational RFC" should be, and it came out that he didn't really know what the differencec are...

> Did he *explicitly mention* that there are no patent issues for RTI?

I asked him, "will it be possible for the Linux community to make a free implementation of the protocol?" and the answer was definitely "yes". Ok, I won't believe it anyway as long as I don't see it somewhere written on paper :)


On Fri, 30 Nov 2001, Curt Wuollet wrote:
> What I haven't been able to discover is what makes publish/subscribe
> desirable enough to justify the complexity on small machines. I have
> complete systems that run less software than these protocols.

As to my understanding the problem is that if you have larger network segments it is desirable to have multicast transmissions, so for example if you have a temperature measuring field device it has to send it's signal to the network only once and e.g. a localized controller is able to pick it up as well as the statistics server (that tries to log plant states), the local service technican or whoever else might be interested in the data. If you do this with multicast you have to send the packet only once.

> Where does the middleware live?

Depends on what you define as "middleware" :) RTPS/NDDS is that part of the stack that is ontop of UDP and below the IDA objects. RTI calls it the middleware.

> The ORB?

Sits ontop of RTPS.

> What makes it a good thing for Mat/LPLC and automation in general? It
> seems like a better fit for client server apps.

The greatest problem is that two years ago everybody has seen Ethernet as a chance to unify the diverging fieldbus market. These days everybody uses Ethernet with his own proprietary protocol ontop, which doesn't change much in the situation. There are lots of implementations out there, and I think that the free software community has to have a look which one fits best into it's model. My impression is that there are two groups on the
market: the global players like Siemens, Rockwell etc on one hand and the IDA/IAONA as a representation of the smaller companies on the other hand. I assume that it will be impossible to establish a non-compatible but working solution based on [insert-your-favourite-open-source-operating-
system-here], even if it is based on better technology. I've talked to several people from companies engaged in IDA and some told me that the RTPS/NDDS part of the IDA model looks like being the only component which is not completely open (whatever that means). Some even told be secretly that they would really be happy to have a non-proprietary solution here, because of the license costs they have to pay to RTI for their implementation.

My conclusion from the discussions is:

a) There will be several solutions for Ethernet based automation in the
future.

b) This is no problem as long as there are at least only 2...3
models out there. If we have significantly more we will quickly
have the same sitiation we had with the fieldbusses.

c) It makes no sense to start something completely new, if you want what
the customers have in mind: easy interoperability between devices of
different supplyers.

d) There are interesting alternatives - a guy had a talk about using
PVM in combination with RTP for distributed automation. But see c).

e) RTPS/NDDS looks like a good solution for the lowlevel stuff, although
it has it's limits. More research has to be done regarding the patent
question, but I have no idea how we can get new information.

Robert
--
+--------------------------------------------------------+
| Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de |
| Pengutronix - Linux Solutions for Science and Industry |
| Braunschweiger Straße 79, 31134 Hildesheim, Germany |
| Phone: +49-5121-28619-0 | Fax: +49-5121-28619-4 |
+--------------------------------------------------------+
_______________________________________________
LinuxPLC mailing list
[email protected]xplc.org http://lists.linuxplc.org/mailman/listinfo/linuxplc

 
C

Curt Wuollet

Thanks Robert

That does help bring it into perspective.
It still seems best suited for one to many or many to many situations.

Regards

cww

--
Free Tools!
Machine Automation Tools (LinuxPLC) Free, Truly Open & Publicly Owned Industrial Automation Software For Linux. mat.sourceforge.net.
Day Job: Heartland Engineering, Automation & ATE for Automotive Rebuilders.
Consultancy: Wide Open Technologies: Moving Business & Automation to Linux. _______________________________________________
LinuxPLC mailing list
[email protected] http://lists.linuxplc.org/mailman/listinfo/linuxplc
 
H

Harald Albrecht

Robert Schwebel wrote:

> I've talked to
> several people from companies engaged in IDA and some told me that the
> RTPS/NDDS part of the IDA model looks like being the only component
> which is not completely open (whatever that means).

Not quite. At least one company, which also happens to be an IDA member, has patents for use of web servers for remote diagnoses, and also told so at the Magdeburg meeting. As far as I remember this was Moeller Comp.

Harald

--
Harald Albrecht
Chair of Process Control Engineering
RWTH Aachen University of Technology
Turmstrasse 46, D-52064 Aachen, Germany
Tel.: +49 241 80-97703, Fax: +49 241 80-92238

_______________________________________________
LinuxPLC mailing list
[email protected] http://lists.linuxplc.org/mailman/listinfo/linuxplc
 
R

Robert Schwebel

On Sat, 1 Dec 2001, Harald Albrecht wrote:
> Not quite. At least one company, which also happens to be an IDA
> member, has patents for use of web servers for remote diagnoses, and
> also told so at the Magdeburg meeting. As far as I remember this was
> Moeller Comp.

There was a message on LinuxDevices some time ago that HP has a patent for embedded web servers as well... if you want to take care about all these trivial patents out there you aren't allowed to implement nothing any more.

Robert
--
+--------------------------------------------------------+
| Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de |
| Pengutronix - Linux Solutions for Science and Industry |
| Braunschweiger Straße 79, 31134 Hildesheim, Germany |
| Phone: +49-5121-28619-0 | Fax: +49-5121-28619-4 |
+--------------------------------------------------------+

_______________________________________________
LinuxPLC mailing list
[email protected] http://lists.linuxplc.org/mailman/listinfo/linuxplc
 
H

Harald Albrecht

Curt Wuollet wrote:

> Hi Harald.
>
> This one kinda snuck up on me. I'm still trying to figure out what all
> the excitement is about. I posted some questions on the general topic
> in response to Robert's post. I'm sure I'm not the only one who could
> use the answers ;^)

It took some time, but now my memory about fishy statistics is finally comming back...

World+dog talks about publisher/subscriber and how good multicasting or broadcasting is. However, as far as I can tell, no one so far took a closer look at the influence of multi/broadcasting on RTI's statistical model or any other public model (are there any?). Especially broadcasting causes packets to appear on all trunks of a switch. (IP Multicasting requires layer 3 handling, so its a router's job and thus will be subject to performance issues when compared to plain layer 2 ethernet frame switching.) And with packets popping up all over the net, I doubt RTI's statistical model will hold. Their only hope are buffering capacities within switches, which could avoid frame collisions, but also cause delays.

BTW -- when both Hirschmann and Siemens talk about RT Ethernet, they are assuming master-slave communication on these segments, much like
PROFIBUS (representatives from both companies showed such slides during presentations at our Chair).

Regards,
Harald

--
Harald Albrecht
Chair of Process Control Engineering
RWTH Aachen University of Technology
Turmstrasse 46, D-52064 Aachen, Germany
Tel.: +49 241 80-97703, Fax: +49 241 80-92238

_______________________________________________
LinuxPLC mailing list
[email protected] http://lists.linuxplc.org/mailman/listinfo/linuxplc

 
C

Curt Wuollet

Thank you Harald,

That's one of the things that bothers me. Broadcast seems like a strange way to go if you want to guarantee response. These bursts on even a lightly loaded network will require time to sort out, besides making large switches unhappy. It's being buzzed a lot and I've had folks mention I'm an idiot for questioning the design, but I'm still digging on who wants it and why. When the benefit isn't obvious, I get curious.

Regards

cww

--
Free Tools!
Machine Automation Tools (LinuxPLC) Free, Truly Open & Publicly Owned Industrial Automation Software For Linux. mat.sourceforge.net.
Day Job: Heartland Engineering, Automation & ATE for Automotive Rebuilders.
Consultancy: Wide Open Technologies: Moving Business & Automation to Linux. _______________________________________________
LinuxPLC mailing list
[email protected] http://lists.linuxplc.org/mailman/listinfo/linuxplc

 
R

Robert Schwebel

On Mon, 3 Dec 2001, Harald Albrecht wrote:
> However, as far as I can tell, no one so far took a closer look at the
> influence of multi/broadcasting on RTI's statistical model or any
> other public model (are there any?).

As I'm a measurement engineer I'll go the other way: I think the first thing is that we need a realtime aware IP stack - that's why I'm currently playing around with RTnet on RTAI. If that's done, it would be great to build up a test environment where real life measurements can be done. This will be a much better base for the guys from the theoretical departments whose job it is to find out why cement¹ works afterwards :)

Robert
¹For those not reading LKML: http://www.uwsg.indiana.edu/hypermail/linux/kernel/0112.0/0096.html
--
+--------------------------------------------------------+
| Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de |
| Pengutronix - Linux Solutions for Science and Industry |
| Braunschweiger Straße 79, 31134 Hildesheim, Germany |
| Phone: +49-5121-28619-0 | Fax: +49-5121-28619-4 |
+--------------------------------------------------------+

_______________________________________________
LinuxPLC mailing list
[email protected] http://lists.linuxplc.org/mailman/listinfo/linuxplc

 
Thread starter Similar threads Forum Replies Date
M General Automation Chat 3
B General Software Chat 10
M Modbus 7
H LinuxPLC Project 19
Top