Welcome on. Uh Today's topic is going to be emerging communication technologies in the automotive domain. I'm Charlotta Jain, working as a product owner in the communication team in the organization of Posh Global Software Technologies in India. So today's agenda is going to be very crisp.

Uh We'll talk about the architectural design or the software design of middleware components, uh the role of the middleware components, uh the performance and optimization of the software design. Uh Matt Pullen like mentioned uh technology is best when it brings people together.

Uh And today uh in this automotive industry, uh we definitely see vehicle to vehicle uh V two X uh different technologies being revolving all around connection communication. And that's where these middleware components in the software design play humongous role. Uh middleware components generally act like a bridge or they are sort of an abstraction layer uh to give you an insight uh when you drive a car, you basically have your Bluetooth connected or it could be your uh multimedia connected and somehow it's just that, you know, you pair up your mobile device, it gets connected and and the audio is working, it's just one of the applications that I'm talking about consider the future where electronic vehicles the EVs are, are going to be become a very futuristic and a very important aspect.

Uh There definitely uh considered a scenario where, you know, you're you're driving an EV like an electronic car and it already tells you that, you know, in the next 30 minutes, your charge is going to get 30% you still need to get a charging spot in the next 30 minutes so that you can complete your destination.

Such kind of a connected intelligence system is is one of the use cases that I could explain here is is going to enter into the automotive industry, it's already there. Uh So what exactly is middleware here? It's, it's like a bridge, you know, for, for a user, it's like application one, application two which I mentioned like it could be a Bluetooth, it could be your, you know, navigation data which is coming from your display. But below this, there are some hardware abstraction layers, there are your drivers, there is the BS P which is board support package and your hardware layers. So basically a camera which is monitoring the real time data around, you know, guiding you in the system if there is an obstacle or not. Uh So basically the hardware interfaces are quite uh hardware specific, but middleware is like an abstraction which is like a plug and play uh which tries to bridge between your applications and, and software and the hardware below it. So the thing that I explained already to you, which is just like uh taken from one of the sources there where it it mentions about. OK. Uh The next charging station is available here. That's your location.

You can already see on this animated ch on the left side, you see a very uh short hardware overview and a software overview and overall architectural design. You have two different processes here. Basically, you have an RV eight and you have an Intel 64 bit processor, but you have certain hardware specific devices like the audio of the memory and then you have some different operating systems running and you have an auto, you have Q nex, you have LINX, you have Android.

So basically, it's, it's kind of a hypervisor system which I'm not going to touch upon. But I'm just trying to unders to, to touch upon that, you know, this operating system is going to say that, you know, it's going to get a critical information from some other ECU like the electronic control unit in a car and tell you that, you know, my charging, the battery charge status for my electronic vehicle is just, you know, going to stay only for some more time, like say next 30 minutes, you need to find a charging station around uh for the next one hour.

So and so, so this critical information now needs to be passed on to this operating system which is running on a different OS which helps for the graphical processing to get displayed. So you have the information coming which needs to be presented to the user, the driver in between. You have different processes, you have different hardwares and you have different operating system. So this is where middleware is like a bridge uh just to stress upon that fact and also to, you know, give, give an architectural high-level design. This is what I was trying to give a very basic overview of about what we would play out with you. So everything depends on, on these middleware design components. Uh starts from use cases. I just touched upon one of one or two use cases, but there are several n number of use cases. Uh There's a lot about application overview and interaction, a lot of component designs involved, of course, uh based on the use case and the application interaction, your component design gets inputs on how I should design my software component. Uh It also depends on system boundaries.

Uh consider a case where we have production systems, we have power system which uh also get into maintenance. Uh There are user access that you need to maintain. OK. In this particular energy management system, I really want a specific user going to come in and come out. I don't want everybody to manage the energy devices uh device management for the same sake. So you have a lot of uh specifics which come into security point of view as well. Who needs to get access? The similar applies for software as well. If I'm designing my software components, I don't want everybody to understand uh everybody to decode what I'm, what, what my middleware component is going to do. So, in addition to that, uh how much memory I can give for the system to in make interaction. You know, if, if I need a system, which where I am going to send 100 MB of data every 10 seconds or just going to the previous slide, let's say this, this particular operating system is going to pump 100 MB of data every 10 seconds. And this is the other operating system which is going to receive the data. Uh Let's say this is going to send five MB of data every two millisecond and this is going to receive the data and vice versa. Here we already know this is the amount of data. So basically you need at least that limited amount of memory so that it can capture the data and send the data out. So that's what I meant by memory footprint system load.

Uh When I have 123456788 plus another eight like 16 processes running in uh and trying to manage a lot of uh business logics with associated with their application. The computer co computing power is going to be demanding is going to be quite high. Uh So your system load also depends with application overview and interaction and how much business logic is included in that process, sir. So this is where uh let's say if I just half have half of it, then you know, I just need half of the computing power there. On top of all this, of course, KPIS also come into picture I have a requirement that my system just get turned on within like three seconds. It has to turn on within one second. When the driver is just plugging in the key, he just turns on the display behind the steering wheel has to come up within a second. So how am I going to match all these requirements? So this is where your requirements drive your component design. Also, it is important to consider the scalability aspects here because the way of communication and the infotainment systems are increasing in our luxury and sophisticated cars uh with uh driver monitoring systems coming into picture, I think uh they, they really drive a key factor in designing the process of type and the technology being used.

So touching upon just to tell in a very crisp way of middleware components, what are they actually really doing? They manage the connectivity or they manage the logics may uh request made by several clients. Scalability is another aspect which I hinted upon. Uh secure access is also very important. And of course, uh they are like the heartbeat, you know, they are like the system for communication. Uh Just a real life analogy, you know, it needs to be talked around. Uh Communication is like like a court and, and Middle West do that. So going a little bit technical with respect to the architectural aspect of the selection and the decision on on, I'm just trying to map the O SI model here. Uh the age old one. So basically on the layer one and layer two, it's basically the physical and the data link. Uh if you look into the physical layer, uh they basically have the serial connection which are pretty slow. But uh at the same time, when your data is quite less and you don't need a high speed, you would go for the serial connection at your physical layer, Ethernet is quite fast, heavy uh reliable. Uh Also depends on what type of uh L five protocol that you use, which I will touch upon in the upcoming slides.

Then you also have a shared memory where you just want to, you know, pump in the data do am M copy and take it from the other end. Uh But of course, uh additional amount of checks being added for transmission retransmission uh your C IC. So basically these are the three different physical layers that you could think about. And that's where you make a decision based on speed based on memory based on cost as which one would fit for you fit for the application that you design. Next comes the network and the transport. Uh Here is where you, you can think about uh the IP based uh basically the internet protocol based. Uh here, it's quite flexible for your L one and L two protocols. But at the same time, there are certain problems that will come out because of the overhead that comes because you have several packet headers getting added up. And that definitely can be an overhead when you have continuous messages and payloads being transmitted across to, to areas.

The layer four L four T transport layer of they can be either synchronous or asynchronous mode of communication. Uh Consider the same here where I'm trying to talk to you and you're listening maybe on the transport layer for an audio message. Uh Your DB PS protocol is is sufficient asynchronous, even if my one or two second of voice gets dropped, you still can hear, you can still make a complete sentence. Uh but consider a synchronous communication where uh for example, in an automotive car, which you're driving and your seatbelt is is not being, you know, put up. This message is very critical for the system and it is important that it gets displayed on your cluster that you know this seatbelt is missing and a warning starts bumping up. So this message is something that I can never afford to lose. So that's where you go for a synchronous communication where there's an acknowledgement and feedback given that yes, the message was received, performance and optimization are coming closer here. Uh So based on, on, on your use case requirements of memory footprint system load cost, uh these are few of the major critical factors that decide on on what you want to pick up in your communication, middleware design.

Uh And of course, the upcoming technologies on top of these uh co layers is is of course some IP based communication which is definitely taking on hold. They have been there, but now their usage and their footprint in this industry is getting just stronger and stronger and stronger.

So uh when, when I talk about performance and optimization, uh Ethernet, yes, they are synchronized. Uh they also support in a synchronized communication. The performance is quite fast, the latency is low. Um And the system footprint needed is also small uh for shared memory.

Uh it can be small and it can be huge, but generally a small one is recommended because memories are expensive. Uh And uh the performance is definitely the fastest, you know, because it's easy to just have a direct memory access, serial communication, full duplex. Uh Of course, uh they are, they are quite uh medium performance uh but the latency is low and medium. So my footprint is small, but performance is something you have to compromise here with respect to full duplex and half duplex. Also uh there's no support for asynchrony organization but the upper slow. So this is where uh the performance and optimization is, is, you know, how much you can give and how much can you take or you know where you can balance off. It all depends on how your system requirements and system design demands for. Uh you have other interesting protocols like some IP uh PRO uh D BAR D bar is a messaging mechanism protocol. MQ. TT is a remote based procedure messa messaging protocol here. Uh The half duplex uh at the L four and the lay of four, you have full duplex. So all these uh different protocols at the lay of five and above are basically fast, slow medium. Uh So if you have something slow performing, of course, uh there's this cost involved is also, you know, compromise there.

Uh But at the same time, how much can you uh go ahead with the memory footprint, the system footprint that's also important there going on uh last but not the least if you have five minutes, I'm open for the question and answers. Uh uh So if someone would like to, you know, uh start off with asking some questions, please post them in the chat. I would be happy to answer. Uh What, who am I? Uh uh Charol Letta Jane, I'm going to complete nine years in BGSW, Bosch. Uh BGSW is the new name which organization has now, but it's Bosch uh since 2013, I've been associated with this organization. Uh My technical skills have gone from more on the embedded domain with different programming languages. Uh But now currently into a techno managerial role, uh who has had the uh experience to work with different domains, be it embedded, be it UXU I design thinking uh over the course of these last nine years of this organization. Uh My hobbies go diverse. Uh They are involved with psychology, networking, old school, trying to write letters in old style even now and making pen pals. Uh I do volunteer. I am interested in mentoring university graduates, which I'm also doing and I also do extensive reverse mentoring as well. Um Education wise, I've completed my instrumentation control engineering in 2013 and I am pursuing my m in psychology, which I would get graduated this year, uh certified achievements.

But above all this, there's one thing I really would like to say, overcome fears or embrace failures and learn from it. They are stepping stones and paths towards success. Uh I have been in this uh overall uh phase where I would say that uh success has come, but at the same time, they were failures. So never, never, ever let fears and failures put you down and, and keep your journey going ahead. Uh And with that, I would like to say thank you to the Rotech Global Conference team uh for giving me this opportunity. And