Hello and welcome to the video series Run-Time Analysis of AUTOSAR Embedded Projects My name is Florian Sommer and I'm responsible for the business development here at the product line embedded software at Vector Informatik in Stuttgart. In this video I'm going to explain a little bit more about the class statistics of the different classes of real-time analysis I introduced in the first video. Talking about statistics, what we're using in this example is two products that you get from Vector on
this CANoe.AMD which many of you might already know. And CANoe.AMD is used in this statistics approach to start measurements via XCP directly on your ECU. In order to do these statistical measurements you will additionally need the vRTM. This stands for runtime measurement and it is a module that you can select within the Vector MICROSAR stack. So in our AUTOSAR stack within the AUTOSAR monitoring and debugging cluster you will find this module RTM. And what happens here is basically, as I said
, with CANoe.AMD. You're triggering a measurement for a certain period of time, 5 ms for example, and then you have a start and stop part in in your code and you will then be able to measure how long this part was executed within the measurement period and the vRTM automatically collects these data and after the end of the measurement periods, provides the minimum, maximum and average runtime, as well as the CPU load within this measurement period. You can imagine it like this that basically wit
hin vRTM, every time that you come to the start point a timer is triggered and every time you come to the stop point this timer is stopped and then afterwards the RTM automatically calculates the different runtimes. It searches for the minimum runtime, the maximum runtime and calculates the average runtime value as well as the CPU load. Let's have a look at the benefits of this solution. The benefit definitely is you have no hardware dependency, so you don't need an oscilloscope, you don't need
a debugger, and you do not need to have any debugging support within your microcontroller available. Additionally, you have tool support, so it's possible to configure the RTM module within the DaVinci Configurator, and you have the CANoe.AMD in order to start and stop the measurements and gather the data. On the downside of this solution what you do not get is details. I mean, OK, it's statistics. But you will not be able to see any preemptions and additionally you only have a limited time fram
e. You can't run this measurement forever, of course, so you will only measure the behavior within a limited time frame. Come so these two points together, no details and only limited time frame, comes with a risk that you have with statistics of course. So for example if we would see a CPU load of 25% you will not be able to tell from this measurement first of all, how the system is behaving before and after the measurement, but also within the measurement period you will have the problem that
for 25% CPU load for example it could be active for the first 25% of your measurement period and in the last 75% of the measurement period it was not running at all. So that's a little bit of a problem. And also for the average and minimum runtimes you also don't know how often this part was activated, so you will not see was it only activated very often within the first 50% and in the last 50% of the measurement period it was not activated at all? That's something you can’t tell from the statis
tics. And as a result of this you are not able to do a detailed requirement analysis. So what you can do, you can report the statistics. You can report the CPU load, but once you have a problem with one of these requirements, so if your runtime is too high or if see that the CPU load is too high, you will not have a sufficient database to dig into the details and find out the root cause and the reason for why this misbehavior is happening. For the detailed analysis of requirements and also findi
ng these root causes, you would need to switch to the next class of timing analysis, which is the timeline and this is something I’m going to show you in the next video. At the end of this video I want to offer you some possibilities to stay in touch and find out more about timing analysis. For that I'm inviting you to join the LinkedIn Group Runtime Analysis in AUTOSAR Projects. In this group you will meet other people working in this field, sharing their experiences and solutions for this topi
c, and you will of course also be able to engage in discussions and ask your questions there. Just search for the group directly on LinkedIn or if you want to have it easier, I put a QR code here in the video so you can simply scan the QR code and you will be redirected to this group. I would be happy to have you in the group. If you have questions to me directly or if you want to connect with me, I'm inviting you to scan the QR code here on the right. You can also see the link to my profile her
e on LinkedIn. I would be very happy to connect with you and answer any questions you have. Thank you very much for watching this video. I'm looking forward to stay in touch with you.
Comments