Open1722 An IEEE 1722 implementation for research and standardization

This talk presents Open 1722, an open-source implementation of the IEEE 1722 protocol, which is known for its application in audio-video transport and automotive contexts. The speaker discusses the protocol's layer two characteristics, focusing on how it enables the transmission of data over Ethernet networks by encapsulating various protocol data units within Ethernet frames. Open 1722 is described as a versatile library, capable of running on different platforms, including Linux, QNX, and bare metal environments, having evolved from a previous project called libavdtp. The talk highlights its use in bridging automotive CAN bus systems through Ethernet, providing a framework for transmitting essential vehicle data while illustrating integration with various applications. The speaker encourages audience engagement with the project and highlights the importance of open-source implementations for fostering innovation and collaboration in the automotive sector.

[music] >> Yeah, so the presentation is about open 722, which is a open source implementation of the IEEE 72 um protocol. IEEE 722, I think Sebastian said it, I don't expect anybody to uh notice, but it stands for audio video transport protocol or short AVTP. This is a streaming protocol made originally from the professional audio video industry, but later extended also for automotive use. Yeah, on on

on the next slide, I I wanted to start with a little bit of history or let's say how I envision the history behind the standard. So, I imagine because I I started using it when this was around for a long time and when I look at these back I think it looks to me like some people came together and thought, "Okay, there are lots of different standards

to transport audio, video, and other form of signal-based data tunnel legacy buses over an Ethernet backbone and so on." Um so, yeah, let's just harmonize these use cases in one single standard and and now we have one again another And maybe you know don't know this one because you're using one of the 14 other standards. Nonetheless, use it in some of um of Bosch products and demonstrators

and so on. Yeah, to give a little bit background and how does this AVTP protocol work like? It's basically layer two protocol, which means if you want to transfer data over using this IEEE 1722 format over an Ethernet network, you have your Ethernet header at the beginning, then you have an IEEE 1722 header, and then an IEEE 1722 payload. Um, the header follows is similar like in

a TLV tag length value scheme. Um, defines what actually is in the Next point here, it says batteries not included, so it's really a very simple um, describes only the PDU formats, but not any complex stateful behavior like discovery, auto configuration, also no flow control and so on. This is everything is up to the user. Um, there have been different formats being standardized, so with this original

standard which came from the professional audio video industry. Um, this included basically audio video. Later on in 2016, there the automotive industry brought in a lot of PDU formats to define a standardized way to CAN, LIN, FlexRay and so on over an Ethernet based backbone. These are um, automotive field buses to connect to sensors actuators. Typically, we don't see a lot of going directly to sensors in

automotive context. yeah, in the following we will focus a lot on the transport of CAN over an Ethernet backbone uh use cases, yeah. But here on the right side I also showed like a small system or topology diagram how how use case could look like if you have an electrical control unit which use a an Ethernet backbone it might connect to some gateway that translates this IEE172

protocol formats to then the the signals to the low-level interfaces. So, for example, camera could use maybe CSI to trans to connect to the gateway, send a video stream, and this is then tunneled over an Ethernet backbone to the control unit. In the other direction, you might have an control path to the camera imager where you transport, for example, remotely control an I2C bus to control the

camera imager. Yeah, what we have used quite a lot or where we use this 72 protocol quite a lot is for mostly two different use cases. First, bridge these automotive CAN field buses from different zones in a vehicle to another zone, yeah. take a CAN frame from from a sensor, put it into an Ethernet frame, then translate it back to a CAN frame on another gateway and

all of that in a standardized format. And then on the right side, this is uh the the future evolution. Um so, we see more and more centralized architectures where we don't bridge from physical canvases to physical canvases, have uh just use a virtual canvas in in the vehicle computer. So, now after talking about the technical background, um I want to now come to the um open source

project Open72. where we implemented these um different protocol formats, or at least some of them. So, um this was also uh started, I think, as part of also partially um within a uh public-funded project um HEL4SDV. Um and our project um supports um is very platform-independent. Um we support uh example applications for Linux, QNX. We can also compile it to QNX, and also run uh the serialization

part of the library um also bare metal for all kind of different um platforms. Initially, we started as as a fork of an existing project um called libavdtp, which came from um Intel. Um they were focusing mostly on the audio-video formats. Um but then, this project, I think it wasn't very well maintained. We picked it up um and started changing a lot of things, and at some

point, um we basically changed the entire code base. And the only thing uh remaining of this initial project are now the the test cases. So, that's why at some point, we also decided to um remove these this fork uh from the original project. Um the whole project is available under BSD free core clause license, so you can take it and use it however you please. yeah, I

think the core part of the library is a serializer deserializer for these um standardized PDU formats. Um it's a plain C library, um but can also be wrapped into uh C plus plus, for example, Rust uh and other um programming languages um and just provides an efficient um in-place processing of these uh PDU uh formats. So, if you compare to, for example, XML, you don't need to

translate into uh let's say syntax tree or in a um canonical form, you can directly work on the uh binary representation that you that you also receive or transmit from the network with minimal overhead. And the API released in the programmer from knowing about the bit boundaries of the fields, the field widths, and endianness, and so on. Um which is uh not so intuitive in in these

um protocol specification. Yeah. And this um library here um I here I showed it um it's basically used as parts of other applications. Yeah. For serializing these these PDU formats and parsing them. Yeah. Yeah, I think that's it for the like introduction part uh on the project. I think uh Sebastian will now say a few things and how we actually use this project and combine it also

with some of the Eclipse open source um uh the yeah, some of the Eclipse projects. Uh yes, exactly. Because, I mean, I I'm lucky that there seems not to be too many um Eclipse stuff in the room because normally, if somebody said we are a Covesa project, it triggers some, you know, feelings in in some people who work at Eclipse STV because, yeah, I mean, that that's

also an organization that is doing automotive STV kind of projects and and softwares. But here, I want to give an example. So, unfortunately, to this event, we couldn't bring the demonstrator. I mean, we had it at some hackathons at the PFP and and other events. But just because um this IEEE 1722, I mean, this is cool, you should have also understood it's sort of a building block,

right? This I mean, this is a protocol implementation. It's not as core, right? It's just It's one building block that is hopefully useful for something. And um here is one of the demos um we have. Um you can also find like code in our our repos. Where we show so on the one hand side, and now what we saw before in Aryan's slides was sort of the

architecture things, right? We can package CAN, we can tunnel it and things. And here is like um how how we built it um for real. So, there is like a vehicle computer. You have these So, that's a Linux-based machine in this case. Um you have this Open 1722 um two on it. Um and then you have the This is the classic case you saw on on the

other slide. So, you have control unit in a car that is just connected via CAN because that is what lots of these low-level things um are doing. And then you have this sort of of gateway that connects the CAN parts or the, you know, low-level low-bandwidth things in the car to the, let's say, backbone where your vehicle computers or zone controllers That is more powerful vehicle computers

are. And so, in this case, you have this gateway that needs to do the translation. Basically, take a CAN frame, package it into this IEEE 1722 format. And that is something we saw it on the one slide already. So, here we have a Zephyr-based So, that's a real-time operating system. It can probably also run on ThreadX, but we haven't come around to that yet. But, you know,

it's like this this kind of things as a controller that also runs this open 1722 software packages is um and give it to here. And then now especially in Eclipse, I mean, we are more thinking about the SDV and abstracted kind of software. Although the CAN bus is not the coolest thing you can do. I mean, it's nice that you can receive low-level CAN frames here. So,

what we put on top is then another Eclipse SDV project. Um the KUKSA project which has basically the capability to take CAN frames, apply some conversion logic um to generate something um some signals which um are according to something called the vehicle signal specification. That is another KUKSA uh project. Um but the vehicle signal specification, that is basically um a long list of data that you might

find in a car. So, like, you know, vehicle speed, how fast is the car, location, where's the car, are the doors open or closed, what's the position of the windows. And the special thing on the VSS is that the industry, so the OEMs agree like how to format it. Like the very simple things. They say, "Okay, let's say vehicle speed will be in kilometers per hour and

will be represented as a float." Yeah? [snorts] And that's quite useful. I mean, there are like over 1,000 data points now. And what the KUKSA project is doing is basically providing an API to these abstracted signals and providing the plumbing that you can take something like CAN and convert it. And that is something in in the in the demo that that is done. Basically, you have the

CAN frames um have them converted to this VSS format. Then there's another it's another open protocol, VISS version two. Again, there will not be an exam, but VISS is like a JSON based uh protocol to access this abstracted VSS data. Then you can build something like a dashboard. So, that's sort of the SDV story. If you have VSS data, you can build applications on top and they

they will never change. And that is, let's say, one very typical example how you would use CAN 1722 and the SDV ecosystem. Um another cool thing is so of course in open 1722 we just we can say we just implement what is in the IEEE 1722 so long PDF. Um but since it's open source we can also modify it. Um so what we also did is so

if you dig deep into this 1722 there's always something called ACF. And ACF CAN transports CAN frames, ACF LIN transports LIN frames, and there are lots of these ACF something something. And uh we prototype something which we call AS CFVSS which was sort of the vision where we said okay SDV thoughts we have in in the cockpit and maybe in mobile phone application that is all abstracted

away. Um and the question is how deep in a car um would you work with the standardized data? I mean we always have we will always have some kind of conversion or gateway in the car. That's just how how cars are, right? Because on the very lowest level people use different sensors, different platforms. And here was a classic thing use CAN as is convert it here. Um

what we could also do is we basically um define a sub format for the 1722 um where we describe how would you put this VSS data so this already agreed upon data in the automotive industry um directly uh into 1722 because then the advantage is if you have some small microcontroller down here um that doesn't use legacy software instead of using CAN you can send this VSS

formatted data directly. So on your um SDV stack here you just need to let's say unpack them and use them. That is sort of a more let's say innovative approach um just to show that you can use it like this. IEEE 1722 doesn't care so much. Um OEMs have different opinions about this like you know how deep will you go with SDV, how deep will you change

your data formats and and and your interfaces or will you never touch But if you do this again um on this kind of uh application it doesn't matter whether the data was directly um sent here or if it was converted. And the main thing is also in terms of this session. So I I try to be strong with the logos in here. So this is like a

working system and you see we have these like agreed upon standards like the Kube service as we have the IEEE 1722. We have this open implementation of that. We use Zephyr OS, could be other OSs. So you have [snorts] like here this this kind of combination which is I mean normally I like to go to these events and always you know stuck some things from friend of

mine together and it works really really great, you know, doesn't need to be all Eclipse or all Linux Foundation. Yeah, they can you can combine it. Because especially since it's a building blocks, right? I mean it's harder if it's a full platforms, but for this kind of I heard the term Lego in in one of the keynotes, but I think a Lego can also be a cool

thing, right? If you have one small project that does one thing very well, has clear interfaces, then everybody can take it and that here is true for open would also be true for for Kuksai. So in summary, so what you should basically take from this talk. Now you of course you have a deep understanding what IEEE 1722 is or at least you see that transports data over

Ethernet in a car and that's a big thing coming up, right? More and more Ethernets in cars and this is sort of these you had it with you with your slide like oh no, it's a 15 standard, but it's really like some some consolidation thing because car is a lot brownfield. There are these older, but well working standards and IEEE 1722 is a very nice way to

just wrap them all into Ethernet, transport them all around the car. Then maybe your vehicle doesn't even need to have a CAN bus, right? Because you can just transport it there. Open 1722 is an open source project that implements this standard because I mean IEEE basically gives you PDF. It's a quite it's a good PDF, but it's a PDF you can't run it. So, open 1722 you

can run it. Um it's really a bit low-level software because it runs super on Linux, but you can also run on embedded operating systems, bare metal, um as you said. It can integrate really well with other open source technologies, as in this example I showed, but we also know like in other companies, you often see that at like trade shows, right? People doing demos with open open

1722. Like companies who building Ethernet transceivers, right? I mean, they want to sell hardware, and also they want to slap an SDV or whatever logo on it. Um so, often you see them just grabbing the code because it's there, and then they can say, "Hey, 1722 works." Which is, of course, also good, especially if you like like you are I'm I'm not outside if you're supporter of

this standard, it can really help adoption a little bit, right? You cannot say, "My I have the best PDF," but you can say, "I have the best PDF," and you know, you can clone the Git repo and check check for yourself. And the same way um also there is still a lot of discussion um the ones who are there I 2 W E 1722 has been also

extended last year, this year, depends how you count it. I mean, there are now more formats in it. there's a lot of discussion, and if you're really interested, uh I can give you two, three, five more talks about it, about something called a remote control, which basically so, I put it in layman terms, have the sensors really dumb, uh right? And and put all the control logic

in the vehicle computer. Um there are also lots of discussions about can this be put on top of 1722, on top of this generic transport protocol. I don't have the answers, there's a lot of opinions, but just the fact that you have a basic 1722 open source implementation um helps you a lot in in prototyping this. So, again, you don't go to these standard organizations and say,

"My PowerPoint is the best," but you can say, "My PowerPoint is the best, and I have initial prototype here. You can you can play with it." And that's I think at least especially in terms of um open community for research, the message that these open implementations of open standards really help. Open standards are already nice and I know also in Eclipse we can do standards, right? But

if you combine it with an implementation, that really helps. And for these small building blocks, like which hopefully everybody needs, um they're also yeah, quite open to be used in different projects, in different contexts and can be connected quite well. What we need from you is actually, I mean, it would be good if you become fans of of open 1722, but if you work in completely different

industries, maybe that's that's not the thing, but then you can at least give the code give us a star on GitHub because I also heard several times during this conference that stars are really good if they don't come from bots and you're all real people, so yeah, please give us a star and with that uh thank you very much and if you have any questions, um we're

here for you. Thank you.