simulink for adaptive autosar video -凯发k8网页登录

yeah, good morning. so it gives me great pleasure to be here in stuttgart, the birthplace of the car, maybe, to talk about simulink for autosar adaptive. so just before i start, could we just have a quick show of hands? so, who's using autosar in the audience? quite a few. and who's using adaptive autosar? so one or two. so hopefully there'll be a good mix in this talk.

ok, so this is what i'm going to cover. so first, i'm going to give you some background on how popular autosar is, and also some of the motivations for adaptive, why they've introduced the adaptive platform. then we'll look at autosar support in simulink. we'll do a deep dive on the adaptive platform, and then i'll wrap it up with additional resources. so let's get started with some background on autosar and autosar adaptive.

so autosar classic is, as i'm sure you're aware, is very popular and it's already on the road. here is some user stories and presentations by our customers. so bmw, they talk about model-based software development and autosar. fca, they've got a nice article on model-based development and code generation, lg chem model-based design and iso 262262. and of course, you know, autosar is not just the preserve of automotive companies but also other kind of related industries, and john deere has got a nice article on model-based development and the work that they've been doing.

ok, so this is autosar classic. so-- you know, we've seen how autosar classic is very popular. so that kind of begs the question, why introduce adaptive platform? so there's really two words, automated driving.

so as i'm sure you're well aware, automated driving requires huge amounts of computational power and communication bandwidth, and it also needs to be easily updateable. so there's a lot going on with automated driving. so the autosar organization, they've introduced the adaptive platform. so they've based it on posix operating system. so that's where you're going to get the computational power from.

they've introduced service-based communication. so this is where you're going to get the communication power, and if, of course they make it easily updated bill. so that's where you get the-- you know, you can easily update these things. so all of this is aimed at autonomous driving.

but automated driving systems, they only form some functionality of a modern automotive system. so a question we hear a lot from our customers is how does adaptive platform play with the other platforms? so classic and non-autosar platforms. so it's a question we hear a lot is, how's adaptive going to play with classic?

so it's not going to go away. they're going to co-exist together. and then the second thing is that simulink offers a design environment where you can scale both from components to compositions and also across platforms as well. so that was a brief background to autosar classic and adaptive. so what i'm going to do now is just cover some of the practicalities of using autosar in simulink before we go into-- before we do a deep dive on the adaptive platform.

ok, so a large number of our customers are using simulink to model the classic applications. so what they do, what they predominantly do is model most, if not all, of the application software in simulink. they also model some of the rta and basic software and routine libraries in simulink, depending on the kind of fidelity of the model. so let's have a look at how our customers get autosar, bring their autosar architectures into simulink.

so this slide covers the main step for designing autosar software components. so i'm going to go through each of these main steps in turn. so if we look at the import step, so some users start from arxml, so the software description. then they're going to import that into simulink. so that's just two lines of matlab code. you're going to get a simulink model from that, and then they can elaborate the software component design further. so it's super easy to pull in your architecture into simulink.

so now if we start with an existing simulink model, so let's see how easy that is to configure for autosar. so you can use the autosar component quick start up and that's just going to ask you a few simple questions just to get you started with configuring that model for autosar. and then you're free to-- then you can elaborate your software component design, your implementation and generate codes. so again, super easy. ok, so here i'm going to show a video of that in action. so this is just an existing simulink model.

i'm going to launch the quick start up, the autosar quick start up. that's going to ask one or two questions, such as just to name the component, the path, what type of component it is, and then how you want to set up the interfaces. so here you could import from arxml, or you could just accept defaults from simulink, and then that's it. so you see your models all set up now. you can generate code for your model.

so here, i'm just going to show the autosar dictionary. so if you want to fine tune a few things, you could go into the autosar dictionary. you see the ports, see the interfaces, and then we can go ahead and generate code. so it's very easy to get started with an existing simulation model for autosar.

so that's good. so let's have-- so i've shown how easy it is to get started. so let's look at some of the modeling. so some customer models look like this. some customer models even look like this, very complex. and you're probably asking yourself some of these questions. so which blocks in the model need to be configured for autosar? it's not obvious, just looking at that. how do you change some of those autosar properties in the model, and how do you get more information and help?

so to answer these questions, we've introduced the autosar perspective to the simulink model. so this perspective these are in-model ui components, there's three of them. i'm just going to go through each of these in turn. so there's a help panel. so that's aimed at first-time users, if they wanted some help getting started.

there's also the code mapping spreadsheet. so every element in the simulink model is going to be mapped to this, is going to be shown in this spreadsheet, and you can configure it that way. and then on the right hand side, you've got the property inspector. so if you want to do more advanced configuration, this is where you'd set some of those attributes up.

ok, so another thing we've learned from the classic platform is-- and through talking to you, the customers. so it's important to do functional simulation of autosar basic software, when you're designing your application software components, and that's for kind of a number of reasons. so the application software is going to be calling a lot into basic software. so you're going to be using the basic software modules, and there's going to be lots of calls into the basic software modules.

secondly, the basic software functionality is highly dynamic, so there's a lot of state in the-- so any upfront simulation that you can do against the basic software is just going to save you time, improve quality in the long run. ok, so customers kind of understand that. what they also remark is that the autosar specifications are pretty detailed. this is just one of them.

this is for the diagnostic event manager. as you can see that's 475 pages, that's pretty detailed. so what we've done is we've encapsulated the contents of those specs into the basic software library, and here you can just literally drag the blocks into your model and simulate a functional simulation of basic software.

so i'm just going to show you a little example of that. so here, what i'm modeling is we're doing some fault tolerant-- it's a fault tolerance position controller. so we've got two sensors, and the monitor is just going to choose the best, the sensor that it thinks is-- has not got any faults. so let's play that.

ok, so those are the two sensors, then we've got a monitor component. so we look in the sensor, so we're going to initialize some state using non-volatile memory. so here, i'll just drag that block in. there's a variety of operations you could choose. we're just reading the data from non-volatile memory.

here we lock in the defaults to the diagnostic event manager. so again, there's a few operations that you could choose. these are all operations in the monitor caller interface. so that's the sensor, and then the monitor is just going to inspect to see which sensor is-- choose the best sensor. ok, so those are the components, and then to simulate you just simply drag these service component blocks into your integration model, and then you can immediately press play now and you get a functional simulation of basic software. so you don't have to read the specs, look at the interfaces.

and that's the functional simulation. you can also double click on the blocks and change the parameters away from defaults. ok, so another area that customers ask us about are library routines. so these are a set of mathematical routines for autosar classic. here. i'm showing the interpolation routines. so these five blocks represent 127 functions for autosar.

so the idea here is that you can drag the block into the model, and then you can change the various settings. but we're always going to ensure that you generate a function call for the ifx library using those settings. i will even give you a hint which routine you've targeted there.

and then this is the generated code from this particular setup. so here we see the ifl interpolation. ok, so we've looked at workflows, components, basic software. so just very quickly, how does it all kind of fit together? so let's have a quick look at that.

so we've modeled our software components, we've got our basic software services. we can also put dials and gauges on there. and here, we've got a virtual easy use simulation of the system. ok, so we've looked at the building blocks that we've got in simulink to support autosar.

so in this section, i'm going to do a deep dive on the adaptive platform and pull out some of the key concepts from the adaptive platform. so if we look at the layered software architecture. so at a very high level it's very similar to classic it's the layered software architecture.

so you've got-- they're not called components, they're called applications for adaptive. you've got a runtime environment. it's autosar runtime environment. you've got the autosar foundation libraries and autosar services, and then the hardware as well. so perhaps one of the biggest differences between classic and adaptive is that for adaptive, the applications can call any of the public interfaces for the-- of either the autosar foundation or the autosar libraries. so the surface area of things that the applications can call is much greater than the classic.

and then the other thing to note is that this isn't necessarily bare metal hardware. it could also be virtual, virtualized and running on servers as well for adaptive. so that's the layered software architecture. so i'm going to go through some of the key concepts that we've kind of pulled out. so for key concept number one.

so everything in adaptive is an os process. so the os provides multi-process capability, and then each adaptive application is its own independent process. so compared to classic, it was just one monolithic process. but for adaptive you've got multiple inter-processing processes. and then each application, it's got its own main function, it's own memory space namespace, and it can be single or multi-threaded.

so if we look at some of the process management. so the os provides process scheduling. the execution manager provides lifecycle management, and then the communication manager provides interprocess communication. so you can think of the execution manager and communication manager as equivalent to the rt84 for classic. but those are things that the application calls directly.

so that's key concept number one. so key concept number two, so i'm going to talk about this service orientated interprocess communication. so first of all, let's just look at the interprocess communication. so for adaptive, the ipc can be local or via the communication manager. could be over a network, again, over the communication manager.

and now, if we look at the type of communication. so as i'm sure you're aware, classic's got sender receiver and client server. adaptive has got this notion of service interface, so it can contain three things. so you've got methods, so that's remote procedure calls over the network [inaudible]. events, so i think of messages, and fields so i think of data. so this is the service interface and this is the service-orientated communication aspect for adaptive.

so that's the second key concept. so the third key concept. so everything in adaptive is c . so all the modules all the applications all need to be written in c . so i've covered, you know, three high level kind of key concepts for autosar adaptive. so this is the autosar adaptive roadmap.

so the autosar consortium have released three versions of the standard. some of these customers are early adopters of adaptive. they've all appeared at the 11th autosar often conference last november. and then i'm pleased to say that two weeks ago, we released in [? 19a, ?] our support for autosar adaptive.

so it's interesting to look at some of the motivations for why we support autosar adaptive in simulink. so first and foremost, simulink's heavily used by you guys for autosar and you've asked us to support autosar adaptive. and then secondly from a kind of technology standpoint. so we've already been investing for a number of years in this notion of service-orientated communication. so first by simulink functions and function callers, and also by simulink messages. and then in terms of code generator. we already generate c code and c code. so it's quite a natural fit from a kind of technology standpoint.

and then thirdly, we participate on the standards committee where we both support classic and adaptive. so those are the kind of three high level motivations for the mathworks support in autosar adaptive. so over the next few slides, i'll take some of those concepts and then show you how it maps to simulink. so in adaptive application, it's got both required ports, provided ports. this is the service interface with events, methods, and fields that i kind of showed before. so let's map some of these concepts to simulink.

so first of all, in adaptive application that maps to a model in simulink and then we look at the events they map to. simulink messages in simulink, and the blocks next to the i/o ports, these convert events to signals and we ship these as parts of the autosar block set, for any models that are predominantly kind of signal-based. we look at the other side. so the provided port. so again, an adaptive application maps to a model and then the events here map to simulink messages on the [? eight ?] ports.

so i'm going to kind of pull everything together now from this talk in a demo of our autosar adaptive support. so let's configure this model for autosar adaptive. so first of all, i'm going to set up the system target file to be autosar adaptive tlc, and then launch the quick start for adaptive.

again, it's going to ask us a few questions, you know, what do we want to call the application of the package. and now we're done configuring the model. so these are all the message boards that have been mapped to autosar. and then if we look at the dictionary, you can see the required and provided reports of the application and then on the service interfaces, we've got events and you can set up namespaces for adaptive.

then the xml options. we've got some package configuration here. ok, so that model's now set up for autosar adaptive. so let's generate code for the model. so here we see the model cpp file, and then we're going to look at some of the calls to the communication manager.

so we've got [inaudible], and then we send in the events here, and then the generated arxml. so this is autosar adaptive arxml, and then we've got adaptive application software component, and then the data types. and we also generate the main cpc. so can generate an execute-- you can create an executable for adaptive.

ok, so this is a summary slide of our autosar adaptive support. so you can generate production autosar adaptive c code in simulink. so the workflow is very simple and intuitive. you could take a simulink model, configure it to generate autosar c . you can go into the dictionary, you know, refine those settings. and then after you've configured your model, you can generate the adaptive c code and arxml.

ok so, i'd just like to complete this talk with some information about additional resources. so many thanks for listening, first of all. so if you'd like further information, please visit the website, the autosar blockset website, and also we've got a demo booth downstairs. so please talk to us at the demo booth. so thank you very much. thank you.

[applause]