Raptor Application Monitor Guide

Size: px

Start display at page:

Download "Raptor Application Monitor Guide"

Belinda Farmer
6 years ago
Views:

net New Eagle LLC 3588 Plymouth Road Box #272

1 Raptor Application Monitor Guide Nick Quinnell New Eagle LLC 3588 Plymouth Road Box #272 Ann Arbor, MI P: (877) F: (270) November 10, 2014

2 Contents 1 Overview 2 2 Why have an Application Monitor? 2 3 Application Monitor Basics 2 4 Application Monitor Setup Startup Action Min Idle Time Max Thread Time Access Level Percent Overrun Limit Overrun Action Example Settings Steps Unpausing Establishing Validation Confidence Using the Application Monitor 6 7 Summary 7 List of Figures 1 Application Monitor Settings Application Monitor Timing Diagram Application Monitor Stepping Diagram Example Application Monitor Settings Stepping Through Execution After a Pause Example Application Monitor Calibrations Continued Execution Following Updated Calibrations

3 1 Overview The Raptor Application Monitor provides run-time information about your Raptor application. It analyzes threads to give timing information and CPU utilization. Its primary uses are to troubleshoot task overrun issues and to help ensure robust application performance. The following sections of this document detail the Raptor Application Monitors benefits and use. 2 Why have an Application Monitor? The Raptor Platform provides convenient model based development tools to allow rapid development of control algorithms and seamlessly deploy these solutions to rugged, production-validated electronic control units (ECUs). This system generally works great, however, occasionally you are reminded that you are developing in a constrained embedded environment. Inherent in this environment are limitations on CPU throughput and memory resources. Additionally, creating software that is deployed to sealed, production ready hardware limits the ability to utilize debugging tools common in the embedded software development space, such as a JTAG debugger. Such tools allow the developer to halt CPU execution and inspect CPU state, and even step though the software source code (C files) looking for defects during execution. Thankfully, with a robust, mature code-generation platform like Raptor the types of issues that these tools are generally used to solve have been resolved already and are available in proven software blocks for you to use in your application. In reality, for the controls developer in the Raptor context the source code is really the Simulink model and inspecting the derived (generated) C source code would not necessarily be of much value. However, due to the nature of the inherent constraints of embedded hardware, (limited processing power, limited memory, etc...) at some point something such as a stack overflow, or processor watchdog will happen as you approach these limits. This would normally cause the ECU to exhibit continual or spurious processor reset or other strange behavior. In general, when the processor resets there is not much indication as to the cause of the error because the state of the processor is wiped on reset. Without additional tools, tracing the error can be quite difficult. This is where the Raptor Application Monitor is meant to help. 3 Application Monitor Basics The Application Monitor performs continuous run-time checks on an executing application, monitors key metrics, and will halt the application if something goes wrong. When it stops the application it writes an error status to some user accessible variables for inspection and leaves the calibration protocol running so you can connect to the ECU and inspect these messages to determine the issue. By halting the application before the module resets, the error state can be captured by the user using a calibration tool like CANape, INCA, or Merlin. In Raptor, the user sets the periods of the various tasks used in the model. Because of this, all of the settings within the Application Monitor are in percentages. 4 Application Monitor Setup To set up the Application Monitor, you must add it to your model. The Application Monitor block can be found in the Simulink Library browser at Raptor Application Monitoring. After adding it to your application you may wish to configure its settings. Although the defaults usually work fine to get started, you may want to work with each of the following parameters to tailor the configuration to your needs. A timing diagram (Figure 2) is included at the end of this section to illustrate what a few of the Application Monitor settings refer to.

4 4.1 Startup Action This allows you to configure the startup behavior of the application for debugging. This can be useful in debugging situations where the software you have flashed onto the controller fails to operate. App Monitor Disabled This setting lets the Application Monitor measure the system normally, however, the Application Monitor will not shut down your application in this mode. Run In this setting the application executes normal startup, running user tasks as typically expected. This is the standard operating mode. Pause In this setting the Application Monitor will pause the application immediately after startup. This means that your model will initialize, but the code in your triggered subsystems will never be executed Figure 1: Application Monitor Settings (including subsystems triggered by the background, second, and minute triggers) until you manually change the value of the calibration AppMonitorState. However, the Application Monitor will run as will all XCP tasks (if you have XCP set up in your model). 4.2 Min Idle Time This configures the minimum amount of idle CPU capacity that must be maintained in your model at all times. If the CPU idle capacity goes below this value, the Application Monitor will pause the application. The idle time is defined as the amount of time not spent executing a task between successive calls to the foreground task. This setting (like all other settings in the Application Monitor) is a percentage. In Figure 1 we have the Min Idle Time set to 20%. This means that for a model that has a 5ms Foreground task, there must be at least 1ms of CPU Idle Time between every Foreground call. See Figure 2 for a graphical view of Idle Time. Min Idle Time of 0 Setting the Min Idle Time value to 0 will prevent the Application Monitor from shutting down your application in the event that there is no CPU idle time between subsequent executions of the foreground task. This can be useful in situations where the application may have an acceptable amount of task-overrun. For further details, see the sections below titled Percent Overrun Limit and Overrun Action. 4.3 Max Thread Time The Max Thread Time setting refers to the maximum allowed percentage of a given task s period that the task takes to run. For example, if the Max Thread Time is set to 80%, a task that runs every 5ms and takes at least 4ms to

5 Foreground Idle Time (%) Pct Overrun (%) ms 5ms 10ms 15ms Figure 2: Application Monitor Timing Diagram run will cause the Application Monitor to pause the application. This feature may be deprecated in a future release, so it is advised that it be set to 200% for all applications. 4.4 Access Level The Access Level setting allows an application developer to control the level at which the Application Monitor calibrations can be accessed. When the application is built, several.a2l files will be generated, and these can be distributed along with your binary file to allow third parties some limited calibration access to your application. Generally, the higher access levels are for primary developers and lower levels are for field technicians and the like. 4.5 Percent Overrun Limit Currently all Raptor modules have a cooperative operating system, so tasks that need to be executed will wait for currently-executing tasks to finish. It is possible that future Raptor modules will not have a cooperative operating system, so please use caution with this feature. The current modules (cooperative OS) are the HCM , HCM , HCM , HCM , and HCM-ARM In the event that Min Idle Time is set to 0, the Application Monitor allows the developer to set a limit on the acceptable amount of task-overrun. For example, if Percent Overrun Limit is set to 20, the time between successive calls to a 5ms foreground task can be at most 6ms. The action that the Application Monitor takes in the event of an overrun is detailed in the next section. See Figure 2 for a graphical view of Percent Overrun. 4.6 Overrun Action In the event that the Percent Overrun Limit is reached, this setting determines what action the Application Monitor will take. Currently there are two options. Stop Application This setting will cause the Application Monitor to stop your application tasks from executing. The Application Monitor itself will continue to run, as will all XCP tasks if you have any in your model. Count Occurrences This setting will case the Application Monitor to keep track of the number of times that the application has exceeded the Percent Overrun Limit. With this setting, the Application Monitor will not stop your application regardless of the extent to which your application has exceeded the Percent Overrun Limit.

Foreground Idle Time (%) 0 Pct Overrun (%) 20 0 Timer_Foreground_Steps 0 0 2 50 0 0 1 50 0 0ms 5ms 10ms 15ms 20ms 25ms Application Paused set to 2 by user decrement after 1 run after 2 runs

6 Foreground Idle Time (%) 0 Pct Overrun (%) 20 0 Timer_Foreground_Steps ms 5ms 10ms 15ms 20ms 25ms Application Paused set to 2 by user decrement after 1 run after 2 runs Application Paused Again Figure 3: Application Monitor Stepping Diagram 5 Example The following example will show how the Application Monitor pauses the application and how to restart and step through your application s execution following a pause. 5.1 Settings See Figure 4 for the settings we have in our Application Monitor block. Note that in this example, the Percent Overrun Limit and Overrun Action have no effect since the Min Idle Time is not set to 0 (the Application Monitor will pause execution when CPU Idle Time dips below 10 percent, which will pause execution before any task-overrun is calculated). 5.2 Steps In our example model, we have several tasks running at various rates. The Application Monitor generates a Steps calibration for all tasks in your application (see Figure 6). These calibrations are used to execute your tasks a certain number of times in the event that the Application Monitor pauses your application. See Figure 3 for an example of how the Steps calibrations work. Figure 4: Example Application Monitor Settings

that causes the Application Monitor to pause execution before those 5 steps are completed.

7 In Figure 5, we see that the Timer foreground Steps calibration has been set to 5 after a pause. When the AppMonitorState calibration is changed to Step, the foreground task will execute 5 times and then the Application Monitor will pause the application - unless there is an additional error that causes the Application Monitor to pause execution before those 5 steps are completed. If the Application Monitor pauses execution before those steps are completed, the Steps calibration will show you how many of the original steps remain, and the AppMonitorLastError variable will show you which error caused the most recent pause. 5.3 Unpausing In Figure 6, the Application Monitor has paused execution of our application because we have exceeded the Min Idle Time setting. However, the Application Monitor and XCP tasks are still running. This allows us to change the calibrations in our model to give us more idle time and then change the calibration AppMonitorState to Running to continue executing our application (see Figure 7). 6 Establishing Validation Confidence Using the Application Monitor Figure 5: Stepping Through Execution After a Pause Another use for the Application Monitor is to establish a safety margin for key operating parameters. Once established, these can be verified during system testing and validation. As an example, if your system requires a safety margin of 30% CPU utilization (e.g. system runs <70% CPU usage at all times) then you can set that in the application monitor and conduct your validation testing. After testing you will have confidence that, for the areas of code executed as part of your test plan, you will not exceed the safety margin. You have the option of disabling the Application Monitor via calibration for production releases. Figure 6: Example Application Monitor Calibrations

Figure 7: Continued Execution Following Updated Calibrations 7 Summary The Application Monitor provides a tool for investigating critical control software issues that would otherwise be

8 Figure 7: Continued Execution Following Updated Calibrations 7 Summary The Application Monitor provides a tool for investigating critical control software issues that would otherwise be very difficult to resolve. By properly configuring the Application Monitor you can avoid trial and error troubleshooting when things go wrong during application development and system testing.

Using Vector CANape with Raptor New Eagle Products, Inc.

Using Vector CANape with Raptor New Eagle Products, Inc. March 2018 Using Vector CANape with Raptor Contents Getting Started Guide VECTOR CANAPE...3 INITIAL SETUP...5 MERGING OFFLINE CALIBRATION CHANGES...9