Service-Oriented Arbitration of ADAS Features with Model-Based Design - MATLAB & Simulink
Video Player is loading.
Current Time 0:00
Duration 15:36
Loaded: 0.00%
Stream Type LIVE
Remaining Time 15:36
 
1x
  • Chapters
  • descriptions off, selected
  • captions off, selected
      Video length is 15:36

      Service-Oriented Arbitration of ADAS Features with Model-Based Design

      Darshana Unnikrishnan, KPIT Technologies
      Nandakumar Kaiprath, KPIT Technologies

      See how to design and compare different arbitration strategies of ADAS features with SOA and Simulink. 

      Published: 7 Aug 2023

      So to begin with, I think I'll just give a very brief summary about our company. So KPIT, basically, we are an independent software integration partner for OEMs and tier 1's. We work mostly in the automotive and mobility industry. So we basically bring scale, dependability to build integrated software.

      Broadly speaking, we majorly work in three domains. One is the ADAS domain, electric and power conventional powertrains and the connectivity and digital cockpit. So what you can see is basically the different areas, different companies amount of platforms.

      So we develop our own accelerators platform tools that actually help OEMs and tier 1's in actually developing their software, taking it from a model or prototype to production level. We have almost around-- I think globally around 11,000 employees that work globally.

      What we're here to talk about is the arbitration. This is basically more of a service-oriented architecture that we have developed, keeping arbitration module in mind. We will just go basically on some of the comparisons, how we came up with the design. Demo is a very just-- how we did it in MATLAB.

      To begin with about arbitration. So I think the major problem statement that we have in the ADAS domain is how do we imitate or mimic human's responsiveness to dynamic situations? So in an ADAS system, arbitration is the one that takes a decision regarding vehicle control, I mean, how the vehicle should behave.

      So basically, when we talk about arbitration, it's more of a main computing unit. It takes information such as lane estimation, crash mitigation, safety. It takes all these decisions, comes up with its own priority and actuation of lateral, longitudinal, and hybrid control of the vehicle. So here, initially, I think we will be talking about how the legacy architecture was done and how that differs from the service-oriented architecture.

      Yeah, so in the legacy architecture that you can see on the top, it's more of a signal base. So we have components that perform some sort of a computation, passes on serially to next components. And when we have applications coming up with a decision, it's provided to arbitration.

      So any minor change in applications-- could be a small change, could be a new application-- it affects directly how arbitration scheme works, how it kind of performs. And for this, the entire pipeline, you need to redeploy, revalidate in order to verify that it's all working still fine.

      It's not always feasible. I mean, it's not really desirable. But when we talk about service-oriented architecture, the same modules are broken down to smaller components, software components. These components run on its own. Depends on inputs that come, perform certain calculations, perform certain computations, and provide output.

      Who are the users of these outputs? It's not really the concern of the software component. I mean, it provides an output and it could be used by one or multiple such components. The same way all the information that is calculated or performed by these components are provided to all applications. Again, application subscribes to some of these services does its work, and then sends out its decision probably to the arbitration.

      When we have a new component that comes up-- I mean, you really don't need to modify the entire architecture. You just add the new components, subscribe to all the existing services, do its work, and then probably provide its output. This is how in, I think, broad levels, the difference or comparison between how the legacy architecture is and how current architecture is, so.

      Yeah, so this is basically the arbitration. So when we started, we initially focused on the arbitration block. I mean, what would we actually take into consideration developing this software component?

      We know that we would probably depend on outputs from different components ego state fusion data, situation assessment, maneuver application. So application service registration is more like an application is registering itself so that it's more into keeping cybersecurity, safety level into in consideration.

      So when we come up with an application ID, in our case, we come up with a unique ID, which mentions what the application is itself, what sort of control access it has, lateral, whether it's only lateral, longitudinal or is it a mix of both, what this application can do, what sort of acid level, cycle time. These are some of the things that the arbitration is made aware of.

      So whenever there is a new application, it basically comes with a new ID with all this information. Maneuver requests is, again, what is provided by this applications. So it's more of a very standardized way of defining a maneuver. Nothing specific to application.

      So basically, an application would tell-- I mean, after it receives all the inputs, the application would tell, OK, I would want to do this particular maneuver or maybe avoid or follow a vehicle or change lane, that sort of a maneuver. Nothing more than that. And that is what is provided arbitration.

      Again, we might get multiple maneuvers from multiple applications. It could also be multiple maneuvers from the same application. Basically, a particular application could give multiple maneuvers with different cost factors or different reasons.

      But the arbitration, once it does its calculation, it gives you a winner out. And then that winner is basically, again, informing all the application as to which maneuver has been accepted. So the applications are aware, OK, whether it's either its maneuver has been rejected or may be delayed for some reason. And also, the maneuver command that goes to the next level, which is trajectory control or reference trajectory.

      This is, again, when we started a design, first we break down. I mean, we have a lot of assets that we have developed over the years. I mean, for the last 20 years, we've been working on different features, products. Some of them are in prototype, some are engineering ready, some are in production.

      We had to, again, redesign, refactor some of these components to work in a more so service-oriented architecture. So we come up with different components. This is how-- it's kind of spread. Applications are broken down.

      We have separate definition as to how these components communicate with each other. Most of these sensors would provide inputs to components. Again, the way it works is the radar is basically offering a service, or a camera is offering a service and the components subscribe to the service as a client and it receives input.

      Tomorrow, you might have even leader that could come up later. And it would offer a service with its data and it would be consumed by some other component. Going forward, again, these components talk to each other, again, through services.

      So the outgoing is more of offering a service and the incoming is a client that subscribes to these services. And it provides-- again, information is sent out, goes to applications. Application comes up, subscribe to, again, relevant situations.

      So not every event that is published by situation is used by all the applications because again, AEB would be interested in some events. ACC could be interested in some other events. So basically, based on how the event applications are developed, events are subscribed and utilized.

      Finally, decision basically as to what sort of maneuver should be done is provided to arbitration. Arbitration takes a decision, provides a winner, provides the maneuver, and that's how it goes forward to either longitudinal control, lateral control, and to the end. So this is how we came up with how architecture should look. And then we move on to designing this or to implementing this in MATLAB.

      So again, here, same as in the previous diagram. We have now come up with all our components. Most of the components, like the sensors, communicating with situation assessment is through events. So these are periodic. I mean, even sensors-- again, every sensor, its on periodicity.

      Some run at 30 milliseconds, some at 50. So events are all sent. It's all subscribed, used by these components. These components come up with its own decision computation calculation. Again, offers another event, which is, again, subscribed by maybe a situation assessment here or used by application itself.

      Again, from a situation when it goes-- so again, when I mention all these components talk to each other by services. But when it comes to application, when application comes up with its maneuver, it's more of a fire and forget sort of a thing. So it is part of a service, but it's not an event. It's more of a fire and forget.

      So ACC would send a message as to this is my particular maneuver I would look and want. And it doesn't really wait for a response. Because I mean, ACC, AEB, everybody will send their own requirement. And it's more of a fire and forget so we don't really wait for a response.

      Arbitration takes over and figures out what it has to do. And the way arbitration, again, talks back to the application regarding when we say about the winner, it's more about, again, event-based. And then this could be, again, a trigger on change or basically events that are sent across.

      We really do not make applications, offer any service because tomorrow, if a new application comes up and it's offering a service, there is really nobody subscribing to it. So that's the reason applications don't really. But they do subscribe to services and they do call methods.

      So again, method is more like arbitration is offering a service. And that particular service has a method, which can be called by applications. The way application and control block talks is, again, a method, but it's more of a request and response.

      So it's just a single-- I mean, the arbitration says, I would request so-and-so maneuver and control and control block would get a response back whether it was accepted or rejected. That is how this would work. So all this is basically design implemented. Logic is all part of our existing implementation.

      I think we just work with all this currently. Service-oriented architecture was supposed to be done. As a sample scenario, what we took into consideration here is-- I mean, so we just have a target vehicle, which is running at a probably lower speed. And we have our ego vehicle, which is following the target vehicle.

      And in order to-- I mean, in ACC mode, it goes into kind of a follow mode. So it decreases its speed gradually just to follow the target vehicle. And after a while, there is a possibility that the target vehicle suddenly decelerates, which causes the ego vehicle to switch too. I think more of an emergency, avoid sort of a feature.

      So again, the same way if there were multiple features, like again, AES or AEB, both would provide their own requests as to what it should be doing. Arbitration, again, then decides whether, again, should it ACC, AEB. Again, AEB will have a higher safety requirement priority. And that is where arbitration would decide, OK, apply sudden brake.

      So in our demo, it's nothing really fancy. I mean, it's more like running the models that we created. And the way we actually view it, it's more through its sequence view. So we have all the models that are here and rerun the simulation.

      And once the simulation's run, we actually-- I think the sequence viewer, you can see the steps that have been followed or executed. It's more of a manual. I mean, there is still a lot of work for us to do to integrate it, to have a little more I think visualization sort of way. But we're kind of slowly working towards that.

      So this is mainly how it looks. I mean, the communication bus transfer we kind of see nothing much actually visually that you can observe in this. Yeah, I mean, this was mainly the end of this one.

      The main advantage that we actually see-- I think this is a very known knowledge over the conventional architecture-- is one thing is scalability. I think all components are designed to communicate with services. So it's very easy, like, future enhancements. I mean, you can add something new to use the existing feature services. Existing components don't need to be modified.

      There is reusability. Again, when we add a new feature deployed, I mean, this would, again, use the same services that are already there. You don't really need to modify or redeploy the entire software, which would have happened in conventional architecture.

      Bandwidth and memory requirement is another important thing because for over-the-air transfer-- I mean, over-the-air update, you don't really update the entire software. I mean, it's mostly focused on specific components. You have a component, you want to update it, possibly it's only that that is required. I mean, everything else remains the same.

      Optimization, again, of redundant software components is because, again, between different domains. I mean, you work-- so in a software-defined vehicle, I mean, you are talking across our domains. Not just AD, but it's body, chassis, powertrain, I mean, even connectivity. Everything is all talking together.

      So there is information that you would need from a different domain. Earlier, you probably had to duplicate our additional code. But the way it would work now is that particular domain has a component that offers a service. Any other domain just needs to subscribe to the service and use it. There is no change, there is no specific changes that the other domain has to do in order to support this.

      The other thing that also we are looking into is running components in shadow mode. I mean, so when you are developing maybe a new version of a component, you don't really need to-- I mean, you could deploy that component running in shadow mode because it would still subscribe to the same services.

      So consider AEB. I mean, you want another AEB to be running in the side. Basically, it will subscribe to the same services. The outputs may not really affect the toolchain, but you might probably log it to see how it might vary with two different features.

      I mean, it could even come to lower down components where you want to just test how would this would work with a more original behavior of the feature. I mean, that is one thing that also could be do. I mean, you don't really affect the entire architecture in that case.

      This is basically, in short, our presentation. Nothing much that's what we have to talk. Last is queries. If anybody has any questions, we can try to answer.

      [APPLAUSE]

      Related Products