Table of Content

Introduction

Scope

This application note describes how to configure the WatchDog stack into an AR project.

The document contains an explanation step by step of the workflow to follow to obtain a working project.

The steps required to create and initially configure an RTA-CAR project are covered in the other workflows in this User Guide, so in this workflow we take an existing single core project (based on the VRTA_Standard Starter Kit for RTA-CAR 9.2) and we explain how to configure the Wdg stack.

This application note could be used as a reference for any generic AR based project.

Definitions and Abbreviations

BSW: AUTOSAR Basic Software, Hardware independent service layer

RTE: AUTOSAR Run-Time Environment

OS: AUTOSAR Operating System

SWC: Software Component

Toolchain

It is assumed you are using the RTA-CAR 9.2.0 toolchain:

RTA-CAR 9.2.0 toolchain
ISOLAR-AB	v 9.2.0
RTA-RTE	v 7.5.0
RTA-BSW	v 6.1.2
RTA-OS	v 6.2.0

Prerequisites

The workflow below is designed to be stand-alone.

It is assumed that you are already familiar with how to create and configure an AUTOSAR project with ISOLAR-AB.

If you’ve not done so already, we recommend that you review (and preferably work through) Workflows 01, 02 and 03 to gain a better understanding of ISOLAR-AB and the tools available to create and configure an AUTOSAR project.

WatchDog Stack Overview

WatchDog Stack as described in AUTOSAR 4.2.2 is composed by 3 modules:

WdgM: WatchDog Manager - it is a service of BSW able to supervise the program execution abstracting from the triggering of hardware watchdog entities
WdgIf: WatchDog Interface - it is part of the On Board Device Abstraction Layer and allows the WdgM to handle more Watchdog devices
Wdg: WatchDog Driver - it is part of the MCAL and allows initialization, mode setting and triggering condition setting of a device

Focusing of the most complex module of this stack, WdgM, we will now highlight it’s most important features. The Watchdog Manager supervises the execution of a configurable number of so-called Supervised Entities. When it detects a violation of the configured temporal and or logical constraints on program execution, it takes a number of configurable actions to recover from this failure. The watchdog Manager provides three mechanisms:

Alive supervision – for supervision of timing of periodic software
Deadline supervision – for aperiodic software
Logical supervision – for supervision of the correctness of the execution sequence

Typically a Supervised Entity is a SWC or a runnable and each of them has one or more CheckPoints eventually connected each other through Transitions forming a Graph. Let’s give a closer look at the supervision mechanisms:

Alive Supervision checks if a Supervised Entity is run too frequently or too rarely setting some parameters as a reference cycle which is a time interval in which the entity is checked, expected number of occurrences of a checkpoint in a reference cycle, upper and lower tolerance limits to the expected occurrences;
Deadline Supervision checks the timing between the occurrence of two defined checkpoints, here the main parameters are: minimum and maximum time;
Logical Supervision checks if the execution flow of a program is valid defining some checkpoints and the allowed transitions among them.

The WdgM can handle more than one Supervised Entities and more Wdg devices; for this reason for each Supervised Entity a Local Status is defined which represents the status of the entity as: supervision ok, supervision failed or supervision expired. Depicted below the State machine for the local status, for further details on this topic refer to AR specification.

The combination of all the Supervised Entities configured, results into a Global Status with a state machine similar to the previous one:

The computation of these statuses is computed periodically in the context of the WdgM_MainFunction; in order to set the local status value, the WdgM refers to a series of results of the three supervisions for each Supervised Entity. Refer to the picture below:

In the particular case of an Alive Supervision configured, a useful hint may be to have a look at the picture below for a better understanding of how the algorithm computes the status:

An explanation of this example can be found in the Annex A of WdgM AR specification.

Sample project overview

The sample project we are going to describe implements a single Supervised Entity with a total of three checkpoints:

one used for Alive supervision
two used for deadline supervision

For the alive supervision a new runnable running at a period of 10ms will be created and inside it the checkpoint will be reached; the WdgM will check if in a time interval of 1 second, 100 occurrences of the checkpoints are reached with a tolerance of 5 occurrences lower and upper the expected value.

For the deadline supervision the same runnable will be used and under certain circumstances (a reception of a defined CAN signal) the deadline supervision will be triggered.

Workflow Summary

Here is a summary of the steps that you will be working through in this example.

Step 1. WdgM module configuration

Step 2. Wdg module configuration

Step 3.WdgIf module configuration

Step 4. Os configuration

Step 5. EcuM update

Step 6. BswM update

Step 7. SWC update

Step 8. System update

Step 1. WdgM module configuration

First of all create a new WdgM module from the BSW services:

Configure the WdgMGeneral container setting:

WdgMDefensiveBehaviour: set to true only if DET is used and more than one caller identifier id configured to check their validity
WdgMDemStoppedSupervisionReport: set to true to enable a notification to DEM when the Global status is STOPPED
WdgMImmediateReset: set to true if an alive supervision failure (Global Status to STOPPED) should immediately reset the ECU
WdgMOffModeEnabled: set to true be able to switch the Watchdog off

There are also some toolchain specific parameters to set, the most important are:

WdgMRbDeadlineTimeoutDetect: set to true if the WdgM-MianFunction should detect a timeout in a deadline supervision even if the end checkpoint is never reached (AR speciification doesn’t cover this case)
WdgMRbInterruptLockDisable: to generate in the WdgM_MainFunction the Interrupt Locks
WdgMRbRTEDisabled: if set to true the mode switch indication to RTE will not be generated

Below the configuration used in this project:

In the same container, define the Supervised Entities also: in this case define only one WdgMSupervisedEntity and inside it define three new Checkpoints

and set the references to:

EcuC partition only if partitioning has been used (WdgMEcucPartitionRef)
the starting checkpoint for the Supervised Entity (WdgMInternalCheckpointInitialRef)
the OS counter (see later)
the ending checkpoint for the Supervised Entity (WdgMInternalCheckpointFinalRef)

Finally create a WdgMWatchDog but don’t set any reference for the moment (see later).

Now switch to WdgMConfigSet container and create a new WdgMMode setting the WdgMexpiredSupervisionycleTol, and the WdgMSupervisionCycle that is the period at which the WdgM_Mainfunction will be executed.

Then create a new WdgMAliveSupervision; set the reference to the Checkpoint to be checked and the values of the expected number of occurrences of the checkpoint (WdgmExpectedAliveIndications), the tolerances to this value (WdgMMaxMargin and WdgMMinMargin) and the number of Supervision Cycles to use as time interval for the check (WdgMSupervisionReferenceCycle).

In a similar way create also a WdgMDeadlineSupervision setting the minimum and maximum time values (WdgMDeadlineMax and WdgMdeadlineMin) and the references to
starting and ending checkpoints:

Each WdgMMode needs to be referred to at least one Supervised Entity; this reference is part of a sub-container named WdgMLocalStatusParamss; there must be one sub-container for each Supervised Entity and along with the reference to it (WdgMlocalStatusSupervisedEntityRef) the number of reference cycle with failed alive supervision before the local status of the Supervised Entity goes to EXPIRED (WdgMfailedAliveSupervisionRefCycleTol).

Finally create inside the WdgMMode a new WdgMTrigger; this container is used to set the time interval at which the SetTriggerCondition function will be called to feed the hardware watchdog device. Set the WdgMTriggerConditionValue expressed in msec, the WdgMWatchDogMode to the desired value (in this case, since the virtual target will be used, choosing the SLOW MODE or the FAST MODE doesn’t make any difference); set the reference to the WdgMWatchdog created in WdgMGeneral.

Step 2. Wdg module configuration

Let’s move to the creation of the Driver Wdg; create the module as for the WdgM;

this module is part of the MCAL, thus the setting in this sample project are only valid for the virtual target:

Step 3. WdgIf module configuration

Finally create the On Board Device Abstraction Layer module: the WdfIf. Create this module as done before for WdgM.

Configure at first the WdgIfGeneral

and then the WdgIfDevices; in this case only a WdgIfDevice will be created; set the reference to the device created in the previous module (Wdg).

NB: now that the WdfIfDevice has been created, go back to WdgM and set the reference to this device in WdgMGeneral//WdgMWatchDog.

Step 4. Os configuration

The deadline supervision needs an Os counter reference, thus, open the Os module and create a new counter:

Then go back to the WdgMSupervisedEntity and configure the reference to this item.

Step 5. EcuM configuration

The WdgM, Wdg and Mcu modules need to be initialized in the startup phase of ECU, thus configure two new items in the EcuMDriverInitListOne as shown below:

Step 6. BswM configuration

For WdgM de initialization create a new action:

add the action to the BswM action List "BswM_AL_Shutdown":

Now you can generate the RTA-BSW remembering to edit the configuration executed and add the new modules WdgM and WdfIf

The last thing to do before switching to the System configuration is to edit the integration code;

In particular take a look at WdgM_Bsw_User.c and WdgM_Bsw_User.h files;

They need to be edited creating the functions for each checkpoint using the template generated; in this case only the function for the deadline supervision’s checkpoints have been created while the alive supervision will use the RTE:

WdgM_Bsw_User.c:

WdgM_Bsw_User.h:

Step 7. System configuration SWC update

The generation of the BSW source code, also created the WdgM service component description file which offers some port interface that we are going to use in our SWC.

First of all an existing SWC can be edited or a new one can be created with a new runnable triggered by a timing event:

Now add the following ports:

one for to set the reached checkpoint for the alive supervision; the swmd file of WdgM offer the Client Server port Interface WdgM_LocalSupervision
eventually add an RPort to read the local status of the Supervised Entity using the Mode switch port interface WdgM_LocalMode
eventually add an RPort to read the global status using the Mode switch port interface WdgM_GlobalMode