3 - TechnicalReference_WdgIfs

 
 
 
 
 
 
 
 
 
 
 
 
MICROSAR WDGIF 
Technical Reference 
 
  
Version 1.1.0 
 
 
 
 
 
 
 
 
 
 
 
Authors 
Christian Leder, Rene Isau 
Status 
Released 
 
 
 
 
 
 

---

Technical Reference MICROSAR WDGIF 
Document Information 
History 
Author 
Date 
Version 
Remarks 
Christian Leder, 
2016-03-16 
1.0.0 
First version of the migrated WdgIf 
Rene Isau 
Technical Reference 
Christian Leder 
2016-07-13 
1.1.0 
Update after introduction of native CFG5 
generator 
Reference Documents 
No. 
Source 
Title 
Version 
[1]   AUTOSAR 
AUTOSAR_SWS_WatchdogInterface.pdf 
V2.3.0 
[2]   Vector 
Safety Manual 
 
Informatik 
[3]   AUTOSAR 
AUTOSAR_TR_BSWModuleList.pdf 
V1.4.0 
 
 
 
Caution 
We  have  configured  the  programs  in  accordance  with  your  specifications  in  the 
  questionnaire.  Whereas  the  programs  do  support  other  configurations  than  the  one 
specified  in  your  questionnaire,  Vector´s  release  of  the  programs  delivered  to  your 
company  is  expressly  restricted  to  the  configuration  you  have  specified  in  the 
questionnaire. 
 
 
 
 
© 2016 Vector Informatik GmbH 
Version 1.1.0 
2 
based on template version 5.12.0 

---

Technical Reference MICROSAR WDGIF 
Contents 
1 
Component History ...................................................................................................... 6 
2 
Introduction................................................................................................................... 7 
2.1 
Architecture Overview ........................................................................................ 8 
2.2 
Basic Functionality of the WdgIf ....................................................................... 10 
3 
Functional Description ............................................................................................... 11 
3.1 
Features .......................................................................................................... 11 
3.1.1 
Deviations ........................................................................................ 11 
3.1.2 
Additions/ Extensions ....................................................................... 12 
3.2 
Integration with Fully AUTOSAR Compliant Drivers ......................................... 12 
3.3 
Operation in Multi-Core Systems ..................................................................... 12 
3.3.1 
Independent Watchdog Devices ....................................................... 14 
3.3.2 
WdgIf with a State Combiner ............................................................ 15 
3.3.2.1 
Checking the Slave Trigger Pattern ................................ 17 
3.3.2.2 
Operation of the State Combiner.................................... 18 
3.3.2.2.1 
Synchronous Mode .................................... 18 
3.3.2.2.2 
Asynchronous Mode .................................. 20 
3.3.2.3 
Worst Case Delay .......................................................... 23 
3.3.2.4 
Worst Case Evaluations ................................................. 24 
3.3.2.5 
Optimal Timing ............................................................... 29 
3.3.2.6 
Start-up Phase ............................................................... 30 
3.3.2.7 
Changing the Monitoring Period During Runtime ........... 30 
3.3.2.7.1 
Changing the Monitoring Period in 
Synchronous Mode .................................... 30 
3.3.2.7.2 
Changing the Monitoring Period in 
Asynchronous Mode .................................. 31 
3.3.2.8 
Shared Memory ............................................................. 32 
3.3.2.9 
Limitations of the State Combiner Implementation ......... 33 
3.4 
Memory Sections ............................................................................................. 33 
3.4.1 
Code and Constants ........................................................................ 33 
3.4.2 
Module Variables ............................................................................. 33 
3.4.2.1 
Module Variables with MICROSAR Os Gen6 / 
AUTOSAR Os version 4.0 .............................................. 33 
3.4.2.2 
Module Variables with MICROSAR Os Gen7 / 
AUTOSAR Os version 4.2 .............................................. 34 
3.5 
Error Handling .................................................................................................. 35 
3.5.1 
Development Error Reporting ........................................................... 35 
© 2016 Vector Informatik GmbH 
Version 1.1.0 
3 
based on template version 5.12.0 

---

Technical Reference MICROSAR WDGIF 
4 
Integration ................................................................................................................... 36 
4.1.1 
Static Files ....................................................................................... 36 
4.1.2 
Dynamic Files .................................................................................. 36 
5 
API Description ........................................................................................................... 37 
5.1 
Type Definitions ............................................................................................... 37 
5.2 
State Combiner Type Definitions ...................................................................... 39 
5.3 
Services provided by WdgIf ............................................................................. 42 
5.3.1 
WdgIf_SetMode ............................................................................... 42 
5.3.2 
WdgIf_SetTriggerCondition .............................................................. 42 
5.3.3 
WdgIf_SetTriggerWindow ................................................................ 43 
5.3.4 
WdgIf_GetVersionInfo ...................................................................... 43 
5.3.5 
WdgIf_GetTickCounter ..................................................................... 44 
5.4 
Services used by WdgIf ................................................................................... 44 
6 
Configuration .............................................................................................................. 47 
6.1 
Configuration Variants ...................................................................................... 47 
6.2 
Configuring the State Combiner ....................................................................... 47 
6.2.1 
Manual Configuration for Synchronous Mode................................... 48 
6.2.2 
Automatic and Manual Configuration for Asynchronous Mode ......... 49 
7 
Glossary and Abbreviations ...................................................................................... 51 
7.1 
Glossary .......................................................................................................... 51 
7.2 
Abbreviations ................................................................................................... 52 
8 
Contact ........................................................................................................................ 53 
 
© 2016 Vector Informatik GmbH 
Version 1.1.0 
4 
based on template version 5.12.0 

---

Technical Reference MICROSAR WDGIF 
Illustrations 
Figure 2-1 
AUTOSAR 4.x Architecture Overview ......................................................... 8 
Figure 2-2 
 Watchdog Manager Stack in an AUTOSAR environment ........................... 9 
Figure 2-3 
Layered structure of the Watchdog Interface ............................................ 10 
Figure 3-1 
WdgM Stack on a multi-core system using WdgIf to address 
independent watchdogs for each core ...................................................... 14 
Figure 3-2 
WdgM Stack on a multi-core system using the State Combiner for a 
combined core reaction ............................................................................ 16 
Figure 3-3 
Master and slave run synchronously with a sufficient offset to avoid jitter 
effects (example 1) ................................................................................... 19 
Figure 3-4 
Master and slave run synchronously with a sufficient offset (example 2)... 19 
Figure 3-5 
Master and slave run synchronously with a sufficient offset (example 3)... 20 
Figure 3-6 
Master and slave drifting apart although they have the same configured 
period (Pm = Ps) ........................................................................................ 21 
Figure 3-7 
Master and slave do not drift from each other but jitter effects occur......... 22 
Figure 3-8 
Slave skipping one trigger is not necessarily detected by master in 
asynchronous mode ................................................................................. 22 
Figure 3-9 
Slave erroneously drifting from master but slowly enough so that no 
failure is detected ..................................................................................... 23 
Figure 3-10 
Worst case delay of the State Combiner ................................................... 24 
Figure 3-11 
Worst case evaluation Case 2 .................................................................. 26 
Figure 3-12 
Worst case evaluation Case 4 .................................................................. 28 
Figure 3-13 
Start-up phase, master starts before slave ............................................... 30 
Figure 3-14 
Start-up phase, master starts before slave ............................................... 31 
Figure 3-15 
Asynchronous mode – monitoring period change example (independent 
change) .................................................................................................... 32 
Tables 
Table 1-1 
Component history...................................................................................... 6 
Table 3-1  
Supported AUTOSAR standard conform features ..................................... 11 
Table 3-2  
Not supported AUTOSAR standard conform features ............................... 11 
Table 3-3  
Features provided beyond the AUTOSAR standard .................................. 12 
Table 3-4  
Value selection if trigger window limits change during monitoring ............. 25 
Table 3-5  
Combinations for worst case evaluation .................................................... 25 
Table 3-6  
Code and Constants ................................................................................. 33 
Table 3-7  
WdgIf constants ........................................................................................ 33 
Table 3-8  
Module variables with MICROSAR Os Gen6 / AUTOSAR Os version 4.0 . 34 
Table 3-9  
Module variables MICROSAR Os Gen7 / AUTOSAR Os version 4.2 ........ 34 
Table 3-10  
Service IDs ............................................................................................... 35 
Table 3-11  
Errors reported to DET ............................................................................. 35 
Table 4-1  
Static files ................................................................................................. 36 
Table 4-2  
Generated files ......................................................................................... 36 
Table 5-1  
WdgIf Type Definitions .............................................................................. 39 
Table 5-2  
State Combiner Type Definitions ............................................................... 41 
Table 5-3  
WdgIf_SetMode ........................................................................................ 42 
Table 5-4  
WdgIf_SetTriggerCondition ....................................................................... 43 
Table 5-5  
WdgIf_SetTriggerWindow ......................................................................... 43 
Table 5-6  
WdgIf_GetVersionInfo ............................................................................... 44 
Table 5-7  
WdgIf_GetTickCounter ............................................................................. 44 
Table 5-8  
Services used by the WdgIf ...................................................................... 46 
Table 7-1  
Glossary ................................................................................................... 51 
Table 7-2  
Abbreviations ............................................................................................ 52 
© 2016 Vector Informatik GmbH 
Version 1.1.0 
5 
based on template version 5.12.0 

---

Technical Reference MICROSAR WDGIF 
1  Component History 
The  component  history  gives  an  overview  over  the  important  milestones  that  are 
supported in the different versions of the component.  
Component Version  New Features 
1.00 
Migration of the WdgIf to Vector Informatik GmbH 
2.00 
Introduction of native CFG5 generator 
Table 1-1 
Component history 
 
 
© 2016 Vector Informatik GmbH 
Version 1.1.0 
6 
based on template version 5.12.0 

---

Technical Reference MICROSAR WDGIF 
2  Introduction 
This  document  describes  the  functionality, API  and  configuration  of  the AUTOSAR  BSW 
module WdgIf as specified in [1]. 
 
Supported AUTOSAR Release*: 
4.0.1 
Supported Configuration Variants: 
pre-compile 
Vendor ID: 
WDGIF_VENDOR_ID 
30 decimal 
(= Vector-Informatik, 
according to HIS) 
Module ID: 
WDGIF_MODULE_ID  
43 decimal 
(according to ref. [3]) 
* For the detailed functional specification please also refer to the corresponding AUTOSAR SWS. 
 
This user manual describes the Watchdog Interface (WdgIf), which is part of the Watchdog 
Manager  Stack,  which  is  part  of  the AUTOSAR  ECU Abstraction  Layer. The main WdgIf 
functionality consists of linking one or more Watchdog Drivers to the overlying Watchdog 
Manager module (WdgM). 
For  multi-core  systems,  the  WdgIf  additionally  offers  the  State  Combiner  functionality  to 
allow several WdgM instances, each running on a separate processor core, to share and 
trigger  a  single  watchdog  device.  The  WdgIf  was  developed  according  to  AUTOSAR 
version 4.0.1 [1].  
The  WdgIf  is  compatible  with  this  AUTOSAR  version,  but  not  fully  compliant.  For  the 
deviations, see section Deviations. In any case, if the WdgIf is used with AUTOSAR 4.0.1 
or another version, all requirements described in the Safety Manual [2] must be fulfilled. 
This user manual does not cover safety-related topics. For safety-related requirements for 
the integration and the application of the WdgIf, refer to the Safety Manual [2]. 
© 2016 Vector Informatik GmbH 
Version 1.1.0 
7 
based on template version 5.12.0 

---

Technical Reference MICROSAR WDGIF 
2.1 
Architecture Overview 
The following figure shows where the WdgIf is located in the AUTOSAR architecture. 
 
Figure 2-1  AUTOSAR 4.x Architecture Overview  
The WdgM Stack consists of the hardware-independent modules Watchdog Manager and 
Watchdog Interface (blue rectangle) and a hardware-dependent module Watchdog Driver. 
Figure 2-2 shows the WdgM Stack with its modules in an AUTOSAR environment. 
© 2016 Vector Informatik GmbH 
Version 1.1.0 
8 
based on template version 5.12.0 

---

Technical Reference MICROSAR WDGIF 
 
Figure 2-2   Watchdog Manager Stack in an AUTOSAR environment 
The  WdgM  controls,  through  the  WdgIf  and  the  Wdg,  the  hardware-implemented 
watchdogs, which can be one or more internal or external watchdog devices. 
 
 
Note 
A watchdog device requires a hardware-dependent Wdg driver. 
 
 
 
 
 
 
© 2016 Vector Informatik GmbH 
Version 1.1.0 
9 
based on template version 5.12.0 

---

Technical Reference MICROSAR WDGIF 
2.2 
Basic Functionality of the WdgIf 
The WdgIf is a platform-independent software module and provides an interface to one or 
more  Watchdog  Driver  modules  for  the  WdgM.  The  WdgM  addresses  the  watchdog 
devices  through  the  WdgIf  using  a  device  index  parameter  (DeviceIndex).  The 
DeviceIndex is used by the WdgIf to refer to a specific Wdg driver instance. 
Figure 2-3 shows the layered structure of the WdgM Stack. The attached watchdog device 
can be internal or external. 
 
 
Figure 2-3  Layered structure of the Watchdog Interface 
 
 
© 2016 Vector Informatik GmbH 
Version 1.1.0 
10 
based on template version 5.12.0 

---

Technical Reference MICROSAR WDGIF 
3  Functional Description 
3.1 
Features 
The features listed in the following tables cover the complete functionality specified for the 
WdgIf. 
The AUTOSAR  standard  functionality  is  specified  in  [1],  the  corresponding  features  are 
listed in the tables 
>  Table 3-1   Supported AUTOSAR standard conform features  
>  Table 3-2   Not supported AUTOSAR standard conform features 
Vector Informatik provides further WdgIf functionality beyond the AUTOSAR standard. The 
corresponding features are listed in the table 
>  Table 3-3   Features provided beyond the AUTOSAR standard 
The following features specified in [1] are supported: 
Supported AUTOSAR Standard Conform Features 
The WdgIf provides uniform access to services of the underlying watchdog drivers like mode 
switching and setting trigger conditions. 
Table 3-1   Supported AUTOSAR standard conform features 
3.1.1 
Deviations 
The following features specified in [1] are not supported: 
Not Supported AUTOSAR Standard Conform Features 
The WdgIf calls the function Appl_Det_ReportError() in order to report detected DET errors 
instead  of  calling  the  function  Det_ReportError()  specified  in  AUTOSAR.  For  details,  see 
section Services used by WdgIf. 
Table 3-2   Not supported AUTOSAR standard conform features 
 
 
© 2016 Vector Informatik GmbH 
Version 1.1.0 
11 
based on template version 5.12.0 

---

Technical Reference MICROSAR WDGIF 
3.1.2 
Additions/ Extensions 
The following features are provided beyond the AUTOSAR standard: 
Features Provided Beyond The AUTOSAR Standard 
The  WdgIf  module  checks  for  development  errors  independently  from  the  configuration 
parameter WdgIfDevErrorDetect but reports to the AUTOSAR module Development Error 
Tracer (DET) only if WdgIfDevErrorDetect is set to true. 
In case of multi-core systems, the WdgIf supports the State Combiner functionality which is not 
specified in AUTOSAR. 
If the State Combiner functionality is used, then the WdgIf calls the functions GetSpinlock() 
/ 
ReleaseSpinlock() 
(if 
configuration 
parameter 
WdgIfStateCombinerUseOsSpinlock 
is 
true) 
or 
the 
functions 
Appl_GetSpinlock()  /  Appl_ReleaseSpinlock()  (if  configuration  parameter 
WdgIfStateCombinerUseOsSpinlock is false) in order to use spinlock functionality for 
inter-core synchronization. For details, see section Services used by WdgIf. 
Table 3-3   Features provided beyond the AUTOSAR standard 
3.2 
Integration with Fully AUTOSAR Compliant Drivers 
In  order  to  integrate  the WdgIf  with  a  fully AUTOSAR-compliant  watchdog  driver  set  the 
configuration  parameter  WdgIfUseAutosarDrvApi  to  true.  This  will  result  in  the 
following: 
>  The  AUTOSAR  Wdg_<infix>_SetMode()  is  called  by  WdgIf_SetMode().  The 
parameter DeviceIndex is not passed, since it does not exist in AUTOSAR. 
>  The 
Wdg_<infix>_SetTriggerCondition() 
is 
called 
by 
WdgIf_SetTriggerCondition(). 
The 
parameters 
DeviceIndex 
and 
WindowStart are not passed, since they do not exist in AUTOSAR. 
>  The 
Wdg_<infix>_SetTriggerCondition() 
is 
called 
by 
WdgIf_SetTriggerWindow().  The  parameters  DeviceIndex  and  WindowStart 
are not passed, since they do not exist in AUTOSAR. 
 
 
Note 
If the WdgM is the caller of the WdgIf (i.e. function WdgIf_SetTriggerWindow() is 
  used  to  service  the  watchdog  device),  the  parameter  WindowStart 
WdgMTriggerWindowStart)  has  no  effect,  because  it  cannot  be  passed  to  an 
AUTOSAR-compliant driver. It is then good practice to set it to 0, because this would 
be the functional meaning of its absence. 
 
 
3.3 
Operation in Multi-Core Systems 
The WdgIf can also be integrated into multi-core systems. During the configuration of the 
WdgIf on  several  cores,  it  is  important  to  consider  how  to  connect  each WdgM  instance 
running on a processor core to the correct Wdg driver module or modules via the WdgIf. 
There are two possible approaches for configuring the WdgIf for a multi-core system: 
© 2016 Vector Informatik GmbH 
Version 1.1.0 
12 
based on template version 5.12.0 

---

Technical Reference MICROSAR WDGIF 
>  Independent watchdog devices  
Configuring the WdgIf module so, that the WdgM Stack instance on every processor 
core triggers its own watchdog device independently from the other cores. An example 
of such a system is a multi-core processor which has one internal watchdog device for 
each core. A fault on a certain core results in a watchdog reaction from the core's own 
watchdog device. Depending on its setup this might be a processor reset or only a 
single core reset. 
>  WdgIf with a State Combiner  
Configuring the WdgIf module with a State Combiner so that the WdgM instances 
running on different processor cores can share one watchdog device and use it to 
cause a reset in case of an irreparable error. The watchdog device will be triggered 
only if no WdgM Stack instance reports any error.  
An example is a multi-core processor with an external watchdog connected to it. A 
fault on any processor core results in a watchdog reset. 
 
 
Note 
A combination of the two approaches above is also possible. 
 
 
 
 
 
© 2016 Vector Informatik GmbH 
Version 1.1.0 
13 
based on template version 5.12.0 

---

Technical Reference MICROSAR WDGIF 
3.3.1 
Independent Watchdog Devices 
The  WdgIf  is  configured  to  enable  each  WdgM  Stack  instance  running  on  a  separate 
processor  core  to  trigger  its  own  watchdog  device  independently  from  the  WdgM  Stack 
instances  running  on  the  other  cores. Whether  the  watchdog  device causes a processor 
reset or a core reset depends on the device's configuration. In this case, the WdgM Stack 
instance running on each processor core is acting as if it was running on an independent 
single-core  system.  Configuring  this  scenario  is  also  very  similar  to  the  single-core 
configuration. However, it needs to be ensured that the watchdog device for a certain core 
is  connected  to  the  correct  WdgM  Stack  instance.  Furthermore,  the  configuration 
parameter WdgIfUseStateCombiner must be set to false. 
 deployment WdgM stack on multi-core - independent core reaction
«device»
Microcontroller - independent core reaction
independet core reaction
«device»
«device»
core 0
core 1
WdgM
WdgM
WdgIf
WdgIf
Wdg
Wdg
«device»
«device»
int Wdg 0
int Wdg 1
 
Figure 3-1  WdgM Stack on a multi-core system using WdgIf to address independent watchdogs for each core 
© 2016 Vector Informatik GmbH 
Version 1.1.0 
14 
based on template version 5.12.0 

---

Technical Reference MICROSAR WDGIF 
3.3.2 
WdgIf with a State Combiner 
The State Combiner is a platform-independent piece of software that is implemented as 
an optional feature of the WdgIf module. Its purpose is to enable WdgM instances running 
on different processor cores to share one watchdog device. The State Combiner acts as 
follows: 
>  If  an  error  during  the  WdgM  supervision  is  detected  on  a  core,  then  the  WdgM 
instance  on  this  core  requests  a  reset,  which  the  State  Combiner  retransmits  to  the 
watchdog device. 
>  Furthermore, the State Combiner monitors the trigger pattern of the WdgM instances 
in order to detect runtime errors such as trigger omissions (e.g. one of the processor 
cores stopped working) or too frequent triggers (e.g. due to scheduling problems, an 
WdgM instance is invoked too frequently). 
>  The State Combiner triggers the watchdog device only if none of the WdgM instances 
requests a reset and the trigger patterns of all WdgM instances are correct. 
>  The  State  Combiner  feature  can  be  enabled  by  setting  the  configuration  parameter 
WdgIfUseStateCombiner to true. 
If enabled, the State Combiner instance on one processor core is configured to work in 
master mode, which triggers the actual watchdog device, while State Combiner instances 
on the other processor cores are configured to work in slave mode. In the following the 
State Combiner instance configured to work in master mode is referred to as master and 
the State Combiner instance(s) configured to work in slave mode as slave(s). The slaves 
do  not  trigger  a  watchdog  device  but  only  communicate  with  the  master  via  shared 
memory. The master triggers the actual watchdog device if the global status of the WdgM 
instances  on  all  cores  is  other  than  STOPPED.  Therefore,  as  soon  as  the  WdgM  Stack 
instance on at least one core has reached the global status STOPPED (i.e. an irreparable 
error  was  detected),  the  watchdog  device  is  –  depending on the configuration  –  reset or 
not triggered anymore. 
 
 
Note 
The  State  Combiner  is  not  visible  to  the  upper  layer  -  the WdgM  instances  on  each 
  processor core. 
 
 
The trigger process in case of a State Combiner is as follows: 
>  The  WdgM  instance  on  a  processor  core  sends  a  trigger  request  to  its  underlying 
WdgIf  instance.  No  watchdog  device  is  triggered,  but  the  corresponding  State 
Combiner instance is invoked - either the master or a slave. 
>  The slave does not trigger but rather signals to the master the trigger request from the 
upper layer. The signaling is performed via shared memory. 
>  If the slave detects an error, it will send a reset request to the State Combiner, also via 
shared memory. 
>  Based on the trigger pattern of the slave (the sequence of the slave's trigger request 
signals  over  a  certain  period  of  time),  the  master  evaluates  whether  the  slave  is 
running correctly. 
© 2016 Vector Informatik GmbH 
Version 1.1.0 
15 
based on template version 5.12.0 

---

Technical Reference MICROSAR WDGIF 
>  The master triggers the actual watchdog device if: 
>  the master's overlying WdgM instance requested a valid watchdog trigger, 
>  no  slave  requested  a  reset  (no  error  reported  by  the  slave's  overlying  WdgM 
instance), and  
>  the trigger pattern of each slave is correct (based on the configuration). 
 
 deployment WdgM stack on multi-core - combined core reaction
«device»
Microcontroller - combined core reaction
combined core reaction
«device»
«device»
«device»
«device»
core 0
core 1
core 2
core 3
WdgM
WdgM
WdgM
WdgM
WdgIf
WdgIf
WdgIf
WdgIf
State Combiner 
State Combiner 
State Combiner 
(master)
(slav e)
(slav e)
write core
read state of
write core 1
2 state
slave cores
state
Wdg ext.
Wdg int.
«device»
Shared Memory
«device»
Wdg int.
«device»
Wdg ext.
 
Figure 3-2  WdgM Stack on a multi-core system using the State Combiner for a combined core reaction 
The  following  must  be  configured  so  that  the  State  Combiner  is  used  by  the  overlying 
WdgM instances to trigger a single watchdog device for all processor cores: 
>  The WdgM instance running on the processor core that controls the physical watchdog 
device  must  be  configured  to  send  a  trigger  request  to  the  master.  (In  the  WdgM’s 
ECU  configuration,  the  WdgIfDeviceRef  parameter  must  be  linked  to  a 
WdgIfStateCombinerMaster  container  of  WdgIf  instead  of  a  WdgIfDevice 
container.) The  trigger  window  needs  to  be set  up  according  to  the  actual  watchdog 
device. 
© 2016 Vector Informatik GmbH 
Version 1.1.0 
16 
based on template version 5.12.0 

---

Technical Reference MICROSAR WDGIF 
>  The WdgM instances running on the other processor cores must be configured to send 
a trigger request to a slave. (In the WdgM’s ECU configuration, the WdgIfDeviceRef 
parameter  must  be  linked  to  a  WdgIfStateCombinerSlave  container  of  WdgIf 
instead of a WdgIfDevice container.)  
 
 
Note 
The trigger window for a slave must match its invocation period. 
  The  slave  is  invoked  by  the  WdgM_MainFunction()  of  the  overlying  WdgM 
instance. 
 
 
>  The  master  must  be  configured  to  trigger  the  watchdog  device.  (In  the WdgIf’s  ECU 
configuration  the  parameter  WdgIfStateCombinerMasterWdgRef  must  reference 
the watchdog device’s driver.) The trigger window with which it will trigger is given by 
the overlying WdgM and retransmitted to the watchdog device by the master. 
>  Following this configuration, the master checks the trigger requests of each slave and 
triggers  the  watchdog  device  only  if  each  slave  triggers  correctly,  no  slave  explicitly 
requested a reset, and the master was triggered correctly. 
>  A reset occurs in the following cases: 
>  The WdgM instance triggering the master requests  a reset  – the reset  request  is 
immediately retransmitted to the watchdog device. 
>  The  WdgM  instance  triggering  a  slave  requests  a  reset  –  the  reset  request  is 
retransmitted to the watchdog device with the next invocation of the master. 
>  The  master  detects  a  shared  memory  corruption  –  it  checks  the  shared  memory 
each time it is invoked – then the master immediately sends a reset request to the 
watchdog device. 
3.3.2.1 
Checking the Slave Trigger Pattern 
Checking  the  trigger  patterns  of  the  slaves  by  the  master  is  based  on  slave  trigger 
counters  which  are  stored  in  shared  memory.  Each  counter  contains  the  number  of 
triggers  for  a  specific slave. The  slave  increases  its  trigger  counter  each  time  it  is  being 
invoked with a valid trigger request by its overlying WdgM instance. The master checks the 
slave trigger counter once per master period or once per a multiple of the master period. 
This  multiplicity  factor  is  called  reference  cycle  and  the  duration  of  time  in  which  the 
master  checks  a  slave  once  is  called  check  interval.  E.g.,  if  the  master  checks  a  slave 
each time the master is invoked, then the reference cycle is 1 and the check interval is one 
master period; if the master checks the slave every other time the master is invoked, then 
the reference cycle is 2 and the check interval is 2 times the master period. 
The master expects that the slave increases its trigger counter in every check interval by a 
certain  number.  This  number  depends  on  the  master  period,  the  slave  period  and  their 
ratio  to  one  another.  The  increase  of  the  slave  trigger  counter  must  be  at  least  1. 
Otherwise the error case of a total slave outage cannot be detected. 
© 2016 Vector Informatik GmbH 
Version 1.1.0 
17 
based on template version 5.12.0 

---

Technical Reference MICROSAR WDGIF 
 
 
Note 
The reference cycle as well as the number of expected slave triggers might be different 
  for each slave. 
 
 
 
3.3.2.2 
Operation of the State Combiner 
There  are  two  possible  operation  modes  –  synchronous  or  asynchronous  mode.  In  the 
synchronous  mode  a  check  interval  exists  such  that  the  number  of  slave  invocations  in 
one check interval is always constant. Therefore the master can be configured to expect a 
constant number of slave trigger counter increments. In the asynchronous mode no such 
check interval exists and the number of slave invocations in one check interval is variable. 
Therefore  the  master  can  only  expect  that  the  number  of  slave  counter  increments  lies 
within a configured or dynamically calculated interval. 
3.3.2.2.1 
Synchronous Mode 
Synchronous mode is given if a check interval can be chosen in which the number of slave 
triggers is always constant. This is the case if both following conditions apply: 
>  No  drifting.  The  master  and  slave  invocations  do  not  drift  apart.  The  ratio  between 
master and slave period remains constant. 
>  Sufficient  invocation  offset.  The  slave  invocation  is  done  with  a  sufficient  offset  from 
the master invocation so that their invocation order is not affected by jitter (jitter effects 
are avoided).  
The jitter effects can be avoided if the offset between master and slave invocations is 
greater than the sum of the maximum possible jitter of the master invocation (jm) and 
the maximum possible jitter of the slave invocation (js). Note that these are the jitters of 
the respective WdgM main functions invoking master and slave. Two offsets need to 
be considered: 
>  The offset from the master invocation in which the master checks the slave to the 
next slave invocation must be greater than jm + js. 
>  The  offset  from  the  slave  invocation  to  the  next  master  invocation  in  which  the 
master checks this slave must be greater than jm + js as well. 
The benefit of the synchronous mode is the shorter interval in which the master can check 
the number of slave triggers (leading to a shorter reaction time) as well as the guaranteed 
detection  of  all  slave  trigger  errors.  Furthermore,  if  the  jitter  becomes  bigger  than  the 
configured offset, this will be detected as an error. 
The  drawback  of  the  synchronous  mode  is  that  if  the  timing  of  the  system  must  be 
changed during runtime (e.g. low power mode), then the ratio between master and slave 
invocation period must remain the same. 
Following scenarios illustrate typical examples of the synchronous mode. 
Figure  3-3  depicts  an  example  of  a  scenario  where  master  and  slave  have  the  same 
period (Pm = Ps). The master checks the slave once in each master period (reference cycle 
© 2016 Vector Informatik GmbH 
Version 1.1.0 
18 
based on template version 5.12.0 

---

Technical Reference MICROSAR WDGIF 
is  1)  and  it  expects  exactly  one  slave  triggering.  The  offset  is  sufficient  to  avoid  jitter 
effects. 
 
Figure 3-3  Master and slave run synchronously with a sufficient offset to avoid jitter effects (example 1) 
Figure 3-4 shows an example of a scenario where the slave's period is a multiple of the 
master's  period  (in  the  example  Ps  =  2*Pm).  As  a  consequence,  the  number  of  slave 
triggers  within  the  check  interval  (reference  cycle  is  2)  is  always  constant  –  one  in  this 
example. The offset is sufficient to avoid jitter effects. 
 
 
Note 
When  master  and  slave  periods  are  referred  in  this  text,  the  configured  periods  are 
  meant. Due to jitter, the actual periods might, of course, be slightly different. However, it 
is important that the conditions for synchronous mode apply. 
 
 
 
 
Figure 3-4  Master and slave run synchronously with a sufficient offset (example 2) 
© 2016 Vector Informatik GmbH 
Version 1.1.0 
19 
based on template version 5.12.0 

---

Technical Reference MICROSAR WDGIF 
Figure 3-5 shows an example of a scenario where the master's period is a multiple of the 
slave's  period  (in  the  example  Pm  =  2*Ps). Again,  the  number  of  slave  triggers  within  a 
master's check interval (reference cycle is 1) is always constant – two in this example. 
 
 
Figure 3-5  Master and slave run synchronously with a sufficient offset (example 3) 
The Synchronous Mode is strongly recommended, because it results in the most accurate 
slave  monitoring  that  can  be  reached  with  a  software  State  Combiner  as  well  as  in  the 
shortest  worst  case  reaction  time  in  case  of  slave  trigger  errors.  Furthermore,  it  detects 
every kind of trigger error because the exact number of expected triggers is known. 
3.3.2.2.2 
Asynchronous Mode 
Asynchronous  mode  is  given  if  the  synchronous  mode  cannot  be  applied  –  in 
asynchronous  mode  no  check  interval  can  be  chosen  such  that  the  number  of  slave 
triggers is constant in each check interval. This is the case if at least one of the following 
applies: 
>  Drifting. Master and Slave invocations drift from one another. 
>  Insufficient  invocation  offset  resulting  in  jitter  effects.  The  offset  between  master  and 
slave  invocations  is  such  that  the  jitter  effects  result  in  a  variable  invocation  pattern 
(number of slave triggers changes between check intervals). 
As a consequence, the master can only check whether the actual number of slave triggers 
is within a certain interval. 
The benefit of the asynchronous mode is that if the timing of the system must be changed 
during runtime, then the ratio between master and slave invocation period need not remain 
the same. In this case, the State Combiner is usually configured to compute the expected 
number of slave triggers dynamically. 
The drawback of the asynchronous mode is the necessity of introducing a tolerance when 
checking  the  slaves  –  the  number  of  expected  slave  triggers  lies  within  an  interval. This 
results in a greater reference cycle and in potentially overlooking slave trigger errors. 
Simple  scenarios  for  each  of  the  two  reasons  that  lead  to  asynchronous  mode  are 
discussed  below. After  that,  two  examples  illustrating  the  drawback  of  the  asynchronous 
mode – the potential overlooking of trigger errors – are presented. 
© 2016 Vector Informatik GmbH 
Version 1.1.0 
20 
based on template version 5.12.0 

---

Technical Reference MICROSAR WDGIF 
Scenario 1: Asynchronous Mode due to Drifting 
Master and slave invocations drift from each other. 
 
Figure 3-6  Master and slave drifting apart although they have the same configured period (Pm = Ps) 
In this example, the master period and the slave period have the same configured length 
but their clocks drift with some rate Δ (positive or negative). The master must check once 
in  n  master  periods  whether  the  number  of  slave  triggers  is  within  an  interval  [tr1; 
tr2]. 
 
 
Note 
The exact reference cycle n and the interval of the number of expected slave triggers 
  depend on the master and slave periods. With increasing jitter the reference cycle also 
increases. 
 
 
Scenario 2: Asynchronous Mode due to Insufficient Offset (Jitter) 
Master  and  slave  do  not  drift  apart.  But  they  are  invoked  at  the  same  points  of  time  or 
close enough to one another so that the jitter affects their sequence. This is illustrated in 
Figure 3-7. 
 
© 2016 Vector Informatik GmbH 
Version 1.1.0 
21 
based on template version 5.12.0 

---

Technical Reference MICROSAR WDGIF 
Figure 3-7  Master and slave do not drift from each other but jitter effects occur 
In this case, the master and slave are running synchronously, but due to the jitter and the 
insufficient  offset  between  master  and  slave  invocations  the  trigger  pattern  is 
unpredictable. For the master and a slave running with the same period the same values 
are derived as for the asynchronous scenario with drifting above – the master checks the 
slave  once  in  every  second  master  period  (reference  cycle  is  2)  and  the  number  of 
expected slave triggers lies in the interval between 1 and 3 inclusively.  
Example of Overlooking Trigger Errors 1: Slave Trigger Omissions 
Figure 3-8 shows an example of how a trigger omission can be overlooked by the master. 
Let the expected slave trigger counter interval be [1; 2]. During the first check interval, 
the  slave  is  invoked  correctly  (as  expected  by  the  master).  During  the  second  check 
interval, the slave should have triggered two times, but one trigger is omitted – the master 
cannot detect this trigger error, since the trigger counter interval is not violated. The third 
check interval shows zero triggers and this is out of the interval, hence the trigger error is 
detected. 
 
 
Note 
In this example, a minimum of two consecutive slave invocation omissions will always 
  be detected by the master. 
 
 
 
 
Figure 3-8  Slave skipping one trigger is not necessarily detected by master in asynchronous mode 
Example of Overlooking Trigger Errors 2: Erroneous Slave Drifting 
Another failure that might be missed by the master is the drifting of the slave, which results 
in  triggering  outside  of  the  configured  slave  trigger  window.  The  latter  is  defined  by  the 
parameters  WindowStart  and  Timeout  (corresponding  to  the  configuration  fields 
WdgMTriggerWindowStart  and  WdgMTriggerConditionValue  in  the  WdgM’s 
configuration)  with  which  the  slave  is  invoked  (depicted  below  as  Ws  and Ts,  where  the 
subscript s indicates the slave). A significant deviation of the actual slave trigger window 
from  the  configured  slave  trigger  window  parameters  will  eventually  be  detected  by  the 
master.  However,  smaller  deviations  might  remain  undiscovered.  This  is  visualized  in 
© 2016 Vector Informatik GmbH 
Version 1.1.0 
22 
based on template version 5.12.0 

---

Technical Reference MICROSAR WDGIF 
Figure 3-9. The expected trigger interval is [1; 2], the reference cycle is 2. The slave is 
drifting  from  the  master,  but  does  not  violate  the  expected  trigger  interval;  hence  the 
master cannot detect the drift. 
 
 
Note 
If the master is drifting and triggers outside of its trigger window, the watchdog device 
  reacts. 
 
 
 
Figure 3-9  Slave erroneously drifting from master but slowly enough so that no failure is detected 
Note 
Due  to  the  drawbacks,  using  the  asynchronous  mode  should  be  avoided  and,  if 
  possible, the synchronous mode should be used! 
 
 
3.3.2.3 
Worst Case Delay 
The delay of the State Combiner is defined as the duration from the point in time when a 
failure  occurs  on  the  slave  and  the  point  in  time  when  this  failure  is  escalated  to  the 
watchdog device by the master. The failure on the slave can be a failure detected by the 
WdgM running on the slave’s core or a failure which results in erroneous triggering of the 
slave. Here, a failure on the slave is a slave trigger outage, i.e. discontinuation of the slave 
triggers, and the worst case delay refers to this slave trigger error only. 
 
 
Note 
Drifting  of  the  slave  triggering  might  lead  to  a  longer  detection  time  (in  both, 
  synchronous and asynchronous mode) or might be overlooked by the master (in 
asynchronous  mode  only).  Occasional  slave  trigger  omissions  might  be 
overlooked by the master only in asynchronous mode, but they are detected in 
synchronous mode. 
 
 
Note 
Reset  requests  from  the  slave  are  detected  by  the  master  at  the  end  of  the 
  current master period (and not at the end of the current check interval) in both, 
synchronous and asynchronous mode. 
 
 
 
© 2016 Vector Informatik GmbH 
Version 1.1.0 
23 
based on template version 5.12.0 

---

Technical Reference MICROSAR WDGIF 
The upper limit for the worst case delay of the State Combiner (WCD) in synchronous 
mode is the double maximum duration of the check interval: WCD < 2*n*Tm, where Tm is 
the WdgM  configuration  parameter WdgMTriggerWindowCondition  set  on the master 
core and n is the reference cycle with which the master checks the slave.  
 
 
Note 
Tm  is  the  worst  case  actual  period  of  invocation  of  the  master’s 
  WdgM_MainFunction(), and it is limited by the watchdog device. Tm can also 
be  expressed  as  the  configured  master  invocation  period  plus  the  maximum 
possible jitter of this invocation: Tm = Pm + jm. 
 
 
The  worst  case  scenario  happens  under  the  following  conditions  (illustrated  in  Figure 
3-10). The slave is triggered shortly after the master has successfully checked the slave 
triggers. However, the slave fails right afterwards and is not being triggered anymore, it is 
not  able  to  directly  inform  the  master  of  a  failure  either. At  the  end  of  the  current  check 
interval the master still evaluates the slave as OK if the number of slave triggers  is within 
the expected interval despite the trigger error. Yet, the next  time the master core checks 
the slave core, it detects that the slave has stopped triggering (at the end of the third check 
interval shown in the figure). 
 
Figure 3-10  Worst case delay of the State Combiner 
Note 
Slave trigger errors that do not lead to violation of the expected number of slave 
  triggers interval cannot be detected by the master! 
 
 
3.3.2.4  Worst Case Evaluations 
The  WdgIf  Fault  Reaction  Time  does  not  depend  on  the  monitoring  feature,  but  on  the 
following three aspects: 
>  whether a State Combiner is used or not, 
>  whether an immediate reset or discontinuing of triggers is configured, 
© 2016 Vector Informatik GmbH 
Version 1.1.0 
24 
based on template version 5.12.0 

---

Technical Reference MICROSAR WDGIF 
>  whether the fault is detected in the master application SW or a slave application SW (if 
a State Combiner is used). 
The  time  also  depends  on  the  configured  lengths  of  the  trigger  windows.  If  the  trigger 
window limits do change during monitoring, the according variable in the formulae shall be 
set as follows: 
Formula Variable  
Value Selection 
WdgMTriggerWindowStart (master) 
Set with lowest possible value. 
WdgMTriggerCondition (master)  
Set with highest possible value. 
WdgMTriggerWindowStart (slave) 
Not used. 
WdgMTriggerCondition (slave)  
Set with highest possible value. 
Table 3-4   Value selection if trigger window limits change during monitoring 
There exist 6 different combinations of the three aspects listed above: 
Case   State Combiner used   Escalation kind  
Fault occurs in  
1  
Yes  
Immediate Reset  
Master SW application 
2  
Yes  
Immediate Reset  
Slave SW application 
3  
Yes  
Discontinuing of Triggers  Master SW application 
4  
Yes  
Discontinuing of Triggers  Slave SW application 
5  
No  
Immediate Reset  
n/a 
6  
No  
Discontinuing of Triggers  n/a  
Table 3-5   Combinations for worst case evaluation 
The WdgIf Fault Reaction Time of every combination is discussed in the following: 
 
Case 1 - State Combiner, immediate reset, fault in master,  Case 5 - No State Combiner, 
immediate reset: 
The WdgIf  escalates  the  reset  request  immediately  to  the Wdg  device. The WdgIf  Fault 
Reaction  Time  for  case  1  and  case  5  is  always  0  (in  any  case,  there  is  no  more  cycle 
consumed - not counting the code execution). 
Case 2 - State Combiner, immediate reset, fault in slave: 
>  The  slave  writes  an  immediate  reset  request  to  the  shared  memory  of  the  State 
Combiner. 
>  The master reads the request at the next call of WdgM_MainFunction() and initiates 
the immediate reset. 
The worst case happens 
>  when the master calls its WdgM_MainFunction(), 
>  the slave writes the reset request immediately afterwards and 
>  the  master  calls  its  WdgM_MainFunction()  with  max.  possible  delay 
(WdgMTriggerConditionValue(master)). 
© 2016 Vector Informatik GmbH 
Version 1.1.0 
25 
based on template version 5.12.0 

---

Technical Reference MICROSAR WDGIF 
As 
Figure 
3-11 
shows, 
the 
WdgIf 
Fault 
Reaction 
Time 
is 
WdgMTriggerConditionValue(master). 
Slave writes
reset request
Master
re
r
t
initiates reset
e
et
as
va
as
M
lS
M
iont ion
ion
c
tc
t
n
n
c
Master
n
Fu
Fu
Fu
ain
ain
ain
_M
_M
_M
gM
gM
d
d
gM
d
W
W
W
Slave
WdgMTriggerConditionValue(master)
WdgM Fault Reaction Time
WdgIf Fault Reaction Time
 
Figure 3-11  Worst case evaluation Case 2 
Case  3  -  State  Combiner,  discontinuing  of  triggers,  fault  in  master,  Case  6  -  No  State 
Combiner, discontinuing of triggers:  
There is no action or delay on the WdgIf level. The WdgIf Fault Reaction Time for case 3 
and case 6 is always 0 (in any case, there is no more cycle consumed - not counting the 
code execution). 
 
 
© 2016 Vector Informatik GmbH 
Version 1.1.0 
26 
based on template version 5.12.0 

---

Technical Reference MICROSAR WDGIF 
Case 4 - State Combiner, discontinuing of triggers, fault in slave: 
>  The slave discontinues triggering. 
>  With  every  call  of  WdgM_MainFunction()  on  master  side,  the  master  checks  how 
often the slave has triggered since the previous check. 
>  As  soon  as  the  number  of  slave  triggers  is  outside  the  expected  range,  the  master 
initiates  an  immediate  reset.  (This  is  not  necessarily  with  the  next  call  of 
WdgM_MainFunction() on master side.) 
The worst case happens when 
>  the master checks the number of triggers on slave side since the previous check, 
>  the  slave  sends  an  allowed  number  of  triggers  (with  respect  to  the  next  check  on 
master side) immediately afterwards, 
>  the WdgM Fault Reaction Time ends and the slave discontinues triggering immediately 
afterwards. 
 
 
Note 
Then the WdgIf Fault Reaction Time is (almost): 
          
         2 * WdgIfStateCombinerReferenceCycle * WdgMTriggerConditionValueMaster, 
 
where WdgIfStateCombinerReferenceCycle is the number of 
WdgMSupervisionCycle on master side between two checks of slave triggers. 
 
 
Figure 3-12 demonstrates this: 
>  WdgIfStateCombinerReferenceCycle is 2, 
>  the  slave  sends  an  allowed  number  of  triggers  for  the  1st  check  interval  (i.e.  one 
trigger) before the end of the WdgIf Fault Reaction Time,  
>  the  master  checks  the  slave  triggers  every  2nd  call  of  WdgM_MainFunction  (every 
2nd WdgMTriggerConditionValue (TM)), 
>  the discontinuing of slave triggers is detected at the end of the 2nd check interval. 
© 2016 Vector Informatik GmbH 
Version 1.1.0 
27 
based on template version 5.12.0 

---

Technical Reference MICROSAR WDGIF 
Master checks
Master checks
Master checks
slave triggers
slave triggers
slave triggers
(ok)
and initiates
re
r
r
t
et
e
Trigger
t
reset
as
as
as
M
ev
discontinuation
M
a
M
l
ion
S
t
iont
ion
c
t
c
n
iont
c
n
Master
c
n
Fu
n
Fu
Fu
ain
Fu
re
r
t
ain
e
s
ts
ain
ain
a
a
_M
n M
n M
o
_M
i
oi
_M
tc
tc
gM
_M
n
n
uF
gM
d
uF
gM
gM
ni
d
ni
d
W
d
a
W
a
_M
_M
W
W
M
M
Slave
g
g
d
d
W
W
TM
TM
TM
TM
1st Check Interval
2nd Check Interval
WdgM Fault Reaction Time
WdgIf Fault Reaction Time
 
Figure 3-12  Worst case evaluation Case 4 
Note 
The evaluation of the multiplication factor 
  WdgIfStateCombinerReferenceCycle is as follows: 
If WDGIF_STATECOMBINER_MANUAL_MODE is STD_ON, then 
WdgIfStateCombinerReferenceCycle is as stated in the field 
wdgif_StateCombiner_config_slaveID.WdgIfStateCombinerReferenceCycle (for slave 
with ID). 
Otherwise, the value is automatically evaluated as:  
WdgIfStateCombinerReferenceCycle = next larger natural number of 
(WdgMTriggerConditionValue (on slave side) / WdgMTriggerWindowStart (on master 
side)). 
 
 
 
 
 
 
© 2016 Vector Informatik GmbH 
Version 1.1.0 
28 
based on template version 5.12.0 

---

Technical Reference MICROSAR WDGIF 
3.3.2.5 
Optimal Timing 
The  optimal  timing  results  in  minimal  worst  case  delay.  It  can  be  reached  when  the 
reference  cycle  is  minimal  –  which  is  1.  This  applies  for  both,  synchronous  and 
asynchronous mode. 
Following  must  apply  so  that  the  optimal  reference  cycle  of  1  can  be  reached  in 
synchronous mode. The period of the WdgM main function invoking the master (Pm) is a 
multiple of the period of the WdgM main function invoking the slave (Ps). If Pm = n * Ps, 
where n = 1, 2, 3,…, then the master can check the slave in each master period. 
>  Example (synchronous mode): 
>  Master: Pm = 20ms 
>  Slave: Ps = 10ms 
Within one cycle of the master exactly 2 triggers of the slave are expected.  
The WCD to a failure in the slave is 40 ms. 
The  following  must  apply  so  that  the  optimal  reference  cycle  of  1  can  be  reached  in 
asynchronous mode. The master period must be longer than the slave period, which is 
the  case  if  (WSm  >  Ts),  where  WSm  is  the  WindowStart  of  the  master  and  Ts  is  the 
Timeout  of  the  slave.  (Note  that  for  asynchronous  mode  Ts  and  WSm  are  used  in  the 
example instead of master and slave invocation periods. This is necessary, since the State 
Combiner  calculates  the  number  of  expected  slave  triggers  based  on  them  when 
configured for automatic calculation.) 
>  Example (asynchronous mode): 
>  Master: WSm = 19ms, Tm = 21ms  
>  Slave: WSs = 16ms, Ts = 18ms 
Within n = 1 cycles of the master (at most 21 ms) are 1 to 2 ticks of the slave expected. 
The worst case delay for a failure in the slave is 2 * n * Tm = 42 ms. 
 
 
Note 
Even with the optimal ratio between periods the drawbacks of the asynchronous 
  mode described in chapter Asynchronous Mode apply. 
 
 
 
 
 
© 2016 Vector Informatik GmbH 
Version 1.1.0 
29 
based on template version 5.12.0 

---

Technical Reference MICROSAR WDGIF 
3.3.2.6 
Start-up Phase 
If  the  slave  starts  together  with  or  after  the  master,  then  the  parameter 
WdgIfStateCombinerStartUpSyncCycles should be set to some positive value n so 
that the master starts evaluating the slave triggering not from the first time the master is 
invoked after start up, but after the first n master periods. 
 
 
Note 
n must be big enough so that the master starts evaluating the slaves as soon as 
  possible after the slaves started; and small enough so that the master does not 
start to evaluate before the slaves started. 
 
 
A typical start-up phase setup is illustrated in Figure 3-13: 
 
Figure 3-13  Start-up phase, master starts before slave 
The  slave  (running  on  some  processor  core  B)  starts  later  than  the  master  (running  on 
processor core A). The WdgIfStateCombinerStartUpSyncCycles parameter is set to 
2 so that the master starts checking the slave after the slave has started. Before the slave 
starts,  the  master  triggers  the  watchdog  device  only  according  to  the  trigger  requests  of 
the master’s overlying main function. Note, however, that if a slave’s main function detects 
a  failure  and  explicitly  requests  a  reset,  then  the  master  reacts  even  during  the  start-up 
phase and retransmits the reset request to the watchdog device. 
3.3.2.7 
Changing the Monitoring Period During Runtime 
Changing the monitoring period means that either the processor frequency or the period of 
invocation of master or slave is changed. 
3.3.2.7.1 
Changing the Monitoring Period in Synchronous Mode 
If the monitoring period in a synchronous mode needs to be changed, several things need 
to  be  considered.  It  is  assumed  that  the  State  Combiner  is  configured  manually  with 
synchronous  mode.  For  any  change  of  the  monitoring  period  or  WdgM  main  functions’ 
period: 
>  the number of slave triggers within one check interval must remain the same and 
>  the  change  of  the  monitoring  period  must  be  made  simultaneously  on  master  and 
slave. 
© 2016 Vector Informatik GmbH 
Version 1.1.0 
30 
based on template version 5.12.0 

---

Technical Reference MICROSAR WDGIF 
It is recommended that such a monitoring period change is not made while any instance of 
the WdgM Stack is being executed. 
Figure 3-14 shows an example of monitoring period change in synchronous mode. 
 
Figure 3-14  Start-up phase, master starts before slave 
3.3.2.7.2 
Changing the Monitoring Period in Asynchronous Mode 
If the monitoring period in asynchronous mode needs to be changed, several things have 
to be considered. 
If the State Combiner is manually configured in asynchronous mode, then for any change 
of the master period or slave period the following restriction applies: 
>  After the change the slave must not violate the interval of expected number of triggers. 
In order to meet the previous restriction following recommendations apply: 
>  It is recommended that the ratio between master and slave period remains the same. 
>  It  is  recommended  that  the  monitoring  period  change  is  done  simultaneously  for 
master and slave. 
>  It  is  recommended  that  such  a  monitoring  period  change  is  not  made  while  any 
instance of the WdgM Stack is being executed. 
If the State Combiner is configured for an asynchronous system in automatic mode, then 
for  any  change  of  the  master  period  or  slave  period  there  are  no  restrictions.  Following 
applies: 
>  The  ratio  between  master  and  slave  period  need  not  remain  the  same  as  for  the 
previous  case  (the  master  is  calculating  the  expected  number  of  slave  triggers 
dynamically). 
>  The  monitoring  period  change  needs  not  to  be  made  simultaneously  for  master  and 
slave as for the previous case. 
>  However,  recommended  is  that  such  a  monitoring  period  change  is  not  made  during 
any part of the WdgM Stack is being executed. 
© 2016 Vector Informatik GmbH 
Version 1.1.0 
31 
based on template version 5.12.0 

---

Technical Reference MICROSAR WDGIF 
Figure 3-15 shows an example of a monitoring period change in asynchronous mode (with 
automatic  calculation  of  expected  slave  triggers)  where  first  the  master  changes  its 
monitoring period independently from the slave. At some later point the slave changes its 
monitoring  period  independently.  For  the  invocation period  of  20ms  (fHIGH) it is assumed 
that both, master  and slave  are  invoked  with  following  parameters:  WindowStart  18ms 
and  Timeout  22ms.  For  the  invocation  period  of  40ms  (fLOW)  it  is  assumed  that  both, 
master  and  slave  are  invoked  with  following  parameters:  WindowStart  36ms  and 
Timeout  44ms.  Based  on these monitoring  periods, the  master  calculates the  expected 
number of slave triggers and the reference cycle as shown in the picture. 
 
 
Note 
If  the  ratio  between  master  and  slave  invocation  period  is  the  same,  the 
  calculation  leads  to  the  same  result  for  reference  cycle  and  the  expected 
interval. This is the case if both master and slave run with fHIGH and then both 
with fLOW (because the ratio 20/20 is equal to 40/40). 
 
 
 
Figure 3-15  Asynchronous mode – monitoring period change example (independent change) 
3.3.2.8 
Shared Memory 
The  State  Combiner  instances  use  shared  memory  to  communicate.  Every  counter 
increment of every slave is written to this memory area. The master reads out the shared 
memory  in  order  to  check  the  counter  increments  against  the  expected  counter 
increments. The slave’s trigger requests increment the respective slave’s trigger counter in 
shared  memory. A  reset  request  from  the  slave  is  also  stored  in  the  shared  memory  to 
inform the master. All data in the shared memory is also stored with inverse value in order 
to  ensure  the  detection  of  memory  corruption.  The  current  slave's  WindowStart  and 
Timeout values are also stored in the shared memory. 
Access to the shared memory is protected against concurrent access. The shared memory 
is  only  written  by  the  slaves  and  only  read  by  the  master.  This  is  achieved  by  a 
mutex/semaphore that is configured for this shared memory block. 
© 2016 Vector Informatik GmbH 
Version 1.1.0 
32 
based on template version 5.12.0 

---

Technical Reference MICROSAR WDGIF 
3.3.2.9 
Limitations of the State Combiner Implementation 
The State Combiner layer has the following limitations: 
>  Only  one  watchdog  device  can  be  connected  to  the  master  and  be  triggered.  Other 
watchdog devices can, however, be directly connected with any WdgIf instance (ECU 
description container WdgIfDevice) and not via State Combiner. 
>  It is not allowed to set the WindowStart parameter to 0 for the slave. If the user tries 
to set it, an error code will be returned to the upper layer. 
3.4 
Memory Sections 
3.4.1 
Code and Constants 
Following memory sections need to be set up for WdgIf's code: 
Section 
Description 
WDGIF_START_SEC_CODE / 
Set up manually, e.g. in MemMap.h. 
WDGIF_STOP_SEC_CODE 
Table 3-6   Code and Constants 
Following memory sections need to be set up for WdgIf's constants: 
Section 
Description 
WDGIF_START_SEC_CONST_ 
Set up manually, e.g. in MemMap.h. 
UNSPECIFIED /  
WDGIF_STOP_SEC_CONST_ 
UNSPECIFIED 
Table 3-7   WdgIf constants 
3.4.2 
Module Variables 
Following  memory  sections  need  to  be  set  up  for  WdgIf’s  module  variables  if  the  State 
Combiner functionality is used (otherwise the WdgIf uses no global variables): 
3.4.2.1 
Module Variables with MICROSAR Os Gen6 / AUTOSAR Os version 4.0 
Section 
Description 
WDGIF_START_SEC_VAR_8BIT / 
If the configuration parameter 
WDGIF_STOP_SEC_VAR_8BIT, 
WdgIfGlobalMemoryAppTaskRef is set, then these 
 
sections are renamed according to the configured OS 
WDGIF_START_SEC_VAR_16BIT /  application (the prefix "WDGIF_" is converted to 
WDGIF_STOP_SEC_VAR_16BIT, 
"<OSApp>_", where <OSApp> is the name of the OS 
 
application) and generated as part of WdgIf_MemMap.h. 
WDGIF_START_SEC_VAR_32BIT /  Otherwise they need to be set up manually, e.g. in 
WDGIF_STOP_SEC_VAR_32BIT 
MemMap.h. 
WDGIF_GLOBAL_SHARED_START_S
These sections are always assigned in the generated file 
EC_VAR_ 
WdgIf_MemMap.h to OS sections and renamed to: 
UNSPECIFIED / 
WDGIF_GLOBAL_SHARED_STOP_SE
GlobalShared_START_SEC_VAR_UNSPECIFIED / 
C_VAR_ 
GlobalShared_STOP_SEC_VAR_UNSPECIFIED 
UNSPECIFIED 
If other assignment is required, then they need to be set 
© 2016 Vector Informatik GmbH 
Version 1.1.0 
33 
based on template version 5.12.0 

---

Technical Reference MICROSAR WDGIF 
Section 
Description 
up manually, e.g. in MemMap.h. 
Table 3-8   Module variables with MICROSAR Os Gen6 / AUTOSAR Os version 4.0 
3.4.2.2 
Module Variables with MICROSAR Os Gen7 / AUTOSAR Os version 4.2 
Section 
Description 
WDGIF_START_SEC_VAR_8BIT / 
If the configuration parameter 
WDGIF_STOP_SEC_VAR_8BIT, 
WdgIfGlobalMemoryAppTaskRef is set, then these 
 
sections are renamed according to the configured OS 
WDGIF_START_SEC_VAR_16BIT /  application (the prefix "WDGIF_START_SEC" is converted 
WDGIF_STOP_SEC_VAR_16BIT, 
to "OS_START_SEC_<OSApp>” and "WDGIF_STOP_SEC" 
 
is converted to "OS_STOP_SEC_<OSApp> ", where 
WDGIF_START_SEC_VAR_32BIT /  <OSApp> is the name of the OS application) and 
WDGIF_STOP_SEC_VAR_32BIT 
generated as part of WdgIf_MemMap.h. Otherwise they 
need to be set up manually, e.g. in MemMap.h. 
WDGIF_GLOBAL_SHARED_START_S
These sections are always assigned in the generated file 
EC_VAR_ 
WdgIf_MemMap.h to OS sections and renamed to: 
UNSPECIFIED / 
WDGIF_GLOBAL_SHARED_STOP_SE
OS_START_SEC_GLOBALSHARED_VAR_UNSPECIFIED 
C_VAR_ 
/ OS_STOP_SEC_GLOBALSHARED_VAR_UNSPECIFIED 
UNSPECIFIED 
If other assignment is required, then they need to be set 
up manually, e.g. in MemMap.h. 
Table 3-9   Module variables MICROSAR Os Gen7 / AUTOSAR Os version 4.2 
 
 
© 2016 Vector Informatik GmbH 
Version 1.1.0 
34 
based on template version 5.12.0 

---

Technical Reference MICROSAR WDGIF 
3.5 
Error Handling 
3.5.1 
Development Error Reporting 
By  default,  development  errors  are  reported  to  the  DET  using  the  service 
ApplDet_ReportError() as specified in [1], if development error reporting is enabled 
(i.e. pre-compile parameter WdgIf_DEV_ERROR_DETECT==STD_ON). 
If  another  module  is  used  for  development  error  reporting,  the  function  prototype  for 
reporting the error can be configured by the integrator, but must have the same signature 
as the service ApplDet_ReportError(). 
The reported WdgIf ID is 43. 
The reported service IDs identify the services which are described in 0. The following table 
presents the service IDs and the related services: 
Service ID 
Service 
0x01u 
WdgIf_SetMode 
0x02u 
WdgIf_SetTriggerCondition 
0x03u 
WdgIf_GetVersionInfo 
0x04u 
WdgIf_SetTriggerWindow 
Table 3-10   Service IDs 
The errors reported to DET are described in the following table: 
Error Code 
Description 
0x01u 
API service called with wrong device index parameter 
0x02u 
API service called with NULL_PTR as parameter 
Table 3-11   Errors reported to DET 
 
 
© 2016 Vector Informatik GmbH 
Version 1.1.0 
35 
based on template version 5.12.0 

---

Technical Reference MICROSAR WDGIF 
4  Integration 
The delivery of the WdgIf contains the files which are described in the chapters 4.1.1 and 
4.1.2: 
4.1.1 
Static Files 
File Name 
Description 
WdgIf.c 
WdgIf implementation 
WdgIf.h 
WdgIf API definitions and function declarations 
WdgIf_Types.h 
WdgIf type definitions 
WdgIf_Cfg.h 
Type definitions for the configuration data in generated files 
Table 4-1   Static files 
4.1.2 
Dynamic Files 
The dynamic files are generated by the WdgIf generator. 
File Name 
Description 
WdgIf_Lcfg.c 
Generated configuration of the component. 
WdgIf_Lcfg.h 
Generated header file for the configuration of the component. 
WdgIf_Cfg_Features.h 
This file contains all preprocessor options for the component. 
WdgIf_MemMap.h 
This file contains memory sections relevant for the State Combiner 
functionality . 
Table 4-2   Generated files 
 
© 2016 Vector Informatik GmbH 
Version 1.1.0 
36 
based on template version 5.12.0 

---

Technical Reference MICROSAR WDGIF 
5  API Description 
This section describes the types, functions and interfaces that are imported or provided by 
the WdgIf software layer. 
5.1 
Type Definitions 
This  section  describes  the  types  of  the  parameters  passed  to  the  API  functions  of  the 
WdgIf. 
Type Name 
C-Type 
Description 
Value Range 
WdgIf_InterfaceFunctions c-struct 
Provides 
Std_ReturnType (*Wdg_SetMode) 
Type 
pointers to the  (uint8, WdgIf_ModeType) 
platform-
or: 
specific APIs.  Std_ReturnType 
(*Wdg_SetMode_AR) 
(WdgIf_ModeType) 
 
Pointer  to  the  platform-specific  SetMode 
function. 
Note: Depending on the API type selected 
via 
preprocessor 
switch 
(WDGIF_USE_AUTOSAR_DRV_API), 
the 
function prototype can be different 
Std_ReturnType 
(*Wdg_SetTriggerWindow) (uint8, 
uint16, uint16) 
or: 
void(*Wdg_SetTriggerCondition_A
R) (uint16) 
 
Pointer to the platform-specific 
SetTriggerWindow/ 
SetTriggerCondition function. 
Note: Depending on the API type selected  
via 
preprocessor 
switch 
(WDGIF_USE_AUTOSAR_DRV_API), 
the 
function prototype can be different 
WdgIf_InterfaceFunctions c-struct 
Connects 
const 
PerWdgDeviceType 
platform-
WdgIf_InterfaceFunctions 
dependent 
Type* WdgFunctions 
functions  to  a   
physical 
Pointers to the platform-specific watchdog 
watchdog 
in  driver functions. 
order  to  allow 
several 
Note: If the State Combiner is enabled, 
the NULL pointer is set instead of a 
© 2016 Vector Informatik GmbH 
Version 1.1.0 
37 
based on template version 5.12.0 

---

Technical Reference MICROSAR WDGIF 
watchdogs  of  pointer to the driver functions. 
the 
same  uint8 WdgInstance  
platform 
to 
work 
 
simultaneousl Index of the physical watchdog instance 
y 
(e.g.,  within this platform. 
external 
Note: If the State Combiner is enabled, 
watchdogs). 
the parameter WdgInstance is used to 
address the State Combiner instance 
instead of a physical watchdog device. 
Note: This parameter is used only if the 
preprocessor switch 
WDGIF_USE_AUTOSAR_DRV_API is 
STD_OFF or if the State Combiner is used 
(preprocessor switch 
WDGIF_USE_STATECOMBINER is 
STD_ON). 
WdgIf_InterfaceType 
c-struct 
Main 
WdgIf  const uint8 NumOfWdgs 
configuration   
structure 
Number of watchdogs supported in the 
WdgIf 
const 
WdgIf_InterfaceFunctions 
PerWdgDeviceType* 
WdgFunctionsPerDevice 
 
Reference to the watchdog driver 
functions and watchdog device instances 
const 
WdgIf_StateCombinerCommonConfig
Type 
*WdgIfStateCombinerConfigCommon 
 
Pointer to State Combiner common 
specific configuration data. 
Part of the structure only if State combiner 
is used (WDGIF_USE_STATECOMBINER is 
STD_ON). 
const 
WdgIf_StateCombinerManualConfig
Type 
**WdgIfStateCombinerConfigManua
l 
 
Pointer to an array of data for manual 
configuration. One element for each slave. 
Part of the structure only if State 
Combiner is used 
(WDGIF_USE_STATECOMBINER is 
© 2016 Vector Informatik GmbH 
Version 1.1.0 
38 
based on template version 5.12.0 

---

Technical Reference MICROSAR WDGIF 
STD_ON) and configured manually 
(WDGIF_STATECOMBINER_MANUAL_ 
MODE is STD_ON). 
uint32 
(*Wdg_GetTickCounter) 
(void) 
 
Function pointer to the GetTickCounter 
driver function if the internal tick counter is 
switched on. 
WdgIf_ModeType 
enum 
Mode  of  the  WDGIF_OFF_MODE 
Watchdog 
 
Watchdog disabled 
WDGIF_SLOW_MODE 
 
Long timeout period (slow triggering) 
WDGIF_FAST_MODE 
 
Short timeout period (fast triggering) 
Table 5-1   WdgIf Type Definitions 
5.2 
State Combiner Type Definitions 
This section describes the State Combiner types in case the State Combiner functionality 
is enabled. 
Type Name 
C-Type  Description 
Value Range 
WdgIf_StateCombiner c-struct  State Combiner global 
uint16 SlaveWindowStart  
SharedMemory 
shared data. Read by 
the master and written 
 
by all slave devices. 
Current  WindowStart  value  of  the 
Contains the current 
slave’s trigger request. 
WindowStart and 
Timeout values of the  uint16 SlaveWindowStart_INV  
slave devices and the 
 
Counter values. This is  Inverted  value  of  the  current 
an array with an element  WindowStart of the slave’s trigger 
for each slave. 
request. 
uint16 SlaveTimeout 
 
Current Timeout value of the 
slave’s trigger request. 
uint16 SlaveTimeout_INV 
 
Inverted value of the current 
Timeout of the slave’s trigger 
request. 
© 2016 Vector Informatik GmbH 
Version 1.1.0 
39 
based on template version 5.12.0 

---

Technical Reference MICROSAR WDGIF 
uint16 SlaveCounterValue 
 
Current slave’s trigger counter 
value. 
uint16 
SlaveCounterValue_INV 
 
Inverted value of the current 
Timeout of the slave’s trigger 
request. 
WdgIf_StateCombiner c-struct  State  Combiner  specific  uint8 
CommonConfigType 
configuration 
structure  WdgIfStateCombinerNumberOfS
for the  State  Combiner  -  laves 
common part 
 
Number of slaves configured for the 
State Combiner. 
WdgIf_StateCombinerSpinlock
IdType 
WdgIfStateCombinerSpinlockI
d 
 
Spinlock ID for synchronizing the 
access to the shared memory 
section. 
uint16 
WdgIfStateCombinerStartUpSy
ncCycles 
 
Number of master cycles during 
start-up in which the master does 
not check the slave triggers. 
const 
WdgIf_InterfaceFunctionsTyp
e 
*WdgIfStateCombinerFunction
s 
 
Pointer to the functions of the 
watchdog device driver connected to 
the master. 
WdgIf_StateCombinerSharedMe
mory 
*WdgIfStateCombinerSData 
 
Pointer to the shared memory. 
WdgIf_StateCombiner c-struct  Configuration  structure  uint16 
ManualConfigType 
for  configuring  State  WdgIfStateCombinerReference
Combiner 
manually.  Cycle 
© 2016 Vector Informatik GmbH 
Version 1.1.0 
40 
based on template version 5.12.0 

---

Technical Reference MICROSAR WDGIF 
Used 
only 
if   
preprocessor 
switch  Defines the reference cycle with 
WDGIF_STATECOMBINE which the master will check the 
R_MANUAL_MODE 
is  slave. 
STD_ON. This is an array  uint16 
with an element for each  WdgIfStateCombinerSlaveIncr
slave. 
ementsMin 
 
Minimal number of expected slave 
triggers in one master check 
interval. 
uint16 
WdgIfStateCombinerSlaveIncr
ementsMax 
 
Maximal number of expected slave 
triggers in one master check 
interval. 
Table 5-2   State Combiner Type Definitions 
 
 
© 2016 Vector Informatik GmbH 
Version 1.1.0 
41 
based on template version 5.12.0 

---

Technical Reference MICROSAR WDGIF 
5.3 
Services provided by WdgIf 
5.3.1 
WdgIf_SetMode 
Prototype 
Std_ReturnType WdgIf_SetMode ( uint8 DeviceIndex, WdgIf_ModeType Mode) 
Parameter 
DeviceIndex 
Identifies the watchdog instance 
Mode 
WDGIF_OFF_MODE: Watchdog disabled 
WDGIF_SLOW_MODE: Long timeout period (slow triggering) 
WDGIF_FAST_MODE: Short timeout period (fast triggering) 
Return code 
Std_ReturnType 
E_OK:            API finished successfully 
E_NOT_OK: An error occurred during execution 
Functional Description 
This function maps the SetMode service to the corresponding physical watchdog implementation 
according to the parameter DeviceIndex. 
Particularities and Limitations 
>  Service ID: see table 'Service IDs'  
>  This function is synchronous. 
>  This function is non-reentrant.  
Expected Caller Context 
>  This service is expected to be called in task context. 
Table 5-3   WdgIf_SetMode 
5.3.2 
WdgIf_SetTriggerCondition 
Prototype 
Std_ReturnType WdgIf_SetTriggerCondition ( uint8 DeviceIndex, uint16 Timeout) 
Parameter 
DeviceIndex 
Identifies the watchdog instance 
Timeout 
Timeout value in milliseconds for setting the trigger 
Return code 
Std_ReturnType 
E_OK:            API finished successfully 
E_NOT_OK: An error occurred during execution 
Functional Description 
This function maps the SetTriggerCondition service to the corresponding physical watchdog 
according to the parameter DeviceIndex. 
© 2016 Vector Informatik GmbH 
Version 1.1.0 
42 
based on template version 5.12.0 

---

Technical Reference MICROSAR WDGIF 
Particularities and Limitations 
>  Service ID: see table 'Service IDs'  
>  This function is synchronous. 
>  This function is non-reentrant.  
Expected Caller Context 
>  This service is expected to be called in task context. 
Table 5-4   WdgIf_SetTriggerCondition 
5.3.3 
WdgIf_SetTriggerWindow 
Prototype 
Std_ReturnType WdgIf_SetTriggerWindow ( 
uint8 DeviceIndex, 
uint16 WindowStart, 
uint16 Timeout 
) 
Parameter 
DeviceIndex 
Identifies the watchdog instance 
WindowStart 
Minimum time until next watchdog service is allowed in milliseconds 
Timeout 
Timeout value in milliseconds for setting the trigger 
Return code 
Std_ReturnType 
E_OK:            API finished successfully 
E_NOT_OK: An error occurred during execution 
Functional Description 
This function maps the SetTriggerWindow service to the corresponding physical watchdog according to 
the parameter DeviceIndex. 
Particularities and Limitations 
>  Service ID: see table 'Service IDs'  
>  This function is synchronous. 
>  This function is non-reentrant.  
Expected Caller Context 
>  This service is expected to be called in task context. 
Table 5-5   WdgIf_SetTriggerWindow 
5.3.4 
WdgIf_GetVersionInfo 
Prototype 
void WdgIf_GetVersionInfo ( Std_VersionInfoType* VersionInfoPtr) 
Parameter 
VersionInfoPtr 
Pointer to where to store the version information of this module 
© 2016 Vector Informatik GmbH 
Version 1.1.0 
43 
based on template version 5.12.0 

---

Technical Reference MICROSAR WDGIF 
Return code 
-- 
-- 
Functional Description 
WdgIf_GetVersionInfo returns the version information of this module. 
Particularities and Limitations 
>  Service ID: see table 'Service IDs'  
>  This function is synchronous. 
>  This function is non-reentrant.  
>  This function is only available if preprocessor switch WDGIF_VERSION_INFO_API set to 
STD_ON. 
Expected Caller Context 
>  This service is expected to be called in task context. 
Table 5-6   WdgIf_GetVersionInfo 
5.3.5 
WdgIf_GetTickCounter 
Prototype 
uint32 WdgIf_GetTickCounter (void) 
Parameter 
-- 
-- 
Return code 
uint32 
The current hardware timebase tick counter 
Functional Description 
This function returns the current hardware tick counter. 
Particularities and Limitations 
>  Service ID: see table 'Service IDs'  
>  This function is synchronous. 
>  This function is non-reentrant. 
>  This function is only available if the preprocessor switch WDGIF_INTERNAL_TICK_COUNTER 
is set to STD_ON, i.e. a valid Wdg is referenced in WdgIfInternalTickCounterRef. 
Expected Caller Context 
>  This service is expected to be called in task context. 
Table 5-7   WdgIf_GetTickCounter 
5.4 
Services used by WdgIf 
In  Table  5-8  services  provided  by  other  components,  which  are  used  by  the  WdgIf  are 
listed.  For  details  about  prototype  and  functionality  refer  to  the  documentation  of  the 
providing component. 
© 2016 Vector Informatik GmbH 
Version 1.1.0 
44 
based on template version 5.12.0 

---

Technical Reference MICROSAR WDGIF 
The  external  functions  must  not  degrade  the  quality  level  of  the  WdgIf.  Hence,  the 
possibility to use wrapper functions is provided so that either: 
>  the wrapper function calls the external function (e.g. context switch), or 
>  the wrapper function provides an alternative implementation of the external function. 
 
 
Note 
In  both  cases  each  wrapper  function  must  be  implemented  according  to  the 
  required  quality  level  of  the  system  (e.g. ASIL  D).  For more  information  about 
how  to  implement  the  wrapper  functions  listed  below,  refer  to  the  Safe 
Watchdog Interface Safety Manual. [2] 
All wrapper functions have the prefix “Appl_”. 
 
 
Component 
Function 
Description 
Det / 
Appl_Det_ReportError()  If the preprocessor option 
Appl_Det 
WDGIF_DEV_ERROR_DETECT is set to 
STD_ON, the WdgIf calls the function 
Appl_Det_ReportError(). 
Expected declaration included with 
Appl_Det.h: 
void Appl_Det_ReportError (uint16 
ModuleId, uint8 InstanceId, uint8 
ApiId, uint8 ErrorId); 
Note: If the preprocessor option 
WDGIF_DEV_ERROR_DETECT is set to 
STD_OFF, the WdgIf performs the consistency 
checks but does not report to DET. 
OS 
GetSpinlock() /  
If the State Combiner functionality is used 
ReleaseSpinlock() 
(preprocessor option 
WDGIF_USE_STATECOMBINER is STD_ON) 
and if the preprocessor option 
WDGIF_STATECOMBINER_USE_OS_SPIN_LO
CK is STD_ON, these OS functions are used in 
order to synchronize the State Combiner 
instances running on different processor 
cores. The declaration is included with Os.h. 
Note: If these functions do not meet the target 
quality level of the system, then the wrapper 
functions Appl_GetSpinlock() and 
Appl_ReleaseSpinlock() must be used. 
Note: These functions use the spinlock ID 
configured with the configuration parameter 
WdgIfStateCombinerSpinlockID. This 
spinlock must be initialized before the WdgIf is 
invoked for the first time (i.e. the overlying 
WdgM main function is invoked for the first 
time after system start-up). 
© 2016 Vector Informatik GmbH 
Version 1.1.0 
45 
based on template version 5.12.0 

---

Technical Reference MICROSAR WDGIF 
Appl_Spinlo
Appl_GetSpinlock() /  
If the State Combiner functionality is used 
ck 
Appl_ReleaseSpinlock()  (preprocessor option 
WDGIF_USE_STATECOMBINER is STD_ON) 
and if the preprocessor option 
WDGIF_STATECOMBINER_USE_OS_SPIN_LO
CK is STD_OFF, these user defined functions 
are used in order to synchronize the State 
Combiner instances running on different 
processor cores.  
The expected declarations are included with 
Appl_Spinlock.h: Std_ReturnType 
Appl_GetSpinlock (uint32 ID); 
Std_ReturnType 
Appl_ReleaseSpinlock (uint32 int 
ID); 
Note: These functions use the spinlock ID 
configured with configuration parameter 
WdgIfStateCombinerSpinlockID. This 
spinlock must be initialized before the WdgIf is 
invoked for the first time (i.e. the overlying 
WdgM main function is invoked for the first 
time after system start-up). 
Table 5-8   Services used by the WdgIf 
© 2016 Vector Informatik GmbH 
Version 1.1.0 
46 
based on template version 5.12.0 

---

Technical Reference MICROSAR WDGIF 
6  Configuration 
This section describes the configuration of the WdgIf. Only link time configuration is used 
for the WdgIf. 
6.1 
Configuration Variants 
The WdgIf supports the configuration variants 
>  VARIANT-PRE-COMPILE 
The configuration classes of the WdgIf parameters depend on the supported configuration 
variants. For their definitions please see the WdgIf_bswmd.arxml file. 
The WdgIf can be configured using the following tool:  
>  DaVinci Configurator 5 (AUTOSAR 4 packages only). Parameters are explained within 
the tool.  
The outputs of the configuration and generation process are the configuration source files. 
6.2 
Configuring the State Combiner 
There  are  two  main  configuration  possibilities  for  the  reference  cycle  and  the  expected 
counter increments interval: manual and automatic. 
>  Manual  configuration  allows  that  the  reference  cycle  as  well  as  the  number  of 
expected  slave  triggers  is  entered  manually  per  slave.  Following  applies  for  the 
manual configuration: 
>  Manual configuration is designed for synchronous mode. 
>  Allows  the  user  to  determine  and  configure  the  values  for  reference  cycle  and 
number of expected triggers per trigger. Can be used to optimize reaction time. 
>  Does not allow changing the master or slave period unless the ratio between them 
stays the same. 
>  The State Combiner in manual mode checks whether the number of slave triggers 
corresponds to the configuration – the system integrator must make sure that the 
configured values are correct! 
>  Automatic configuration sets the State Combiner to calculate reference cycle and the 
number  of  expected  slave  triggers  automatically.  Following  applies  for  the  automatic 
configuration: 
>  Automatic configuration is designed for asynchronous mode. 
>  Automatic  calculation  does  not  optimize  reaction  time  (because  the  State 
Combiner  cannot  take  the  offset  into  account  when  calculating  the  reference 
cycle). 
>  Allows change of master period and slave period independently from one another. 
>  The  State  Combiner  in  automatic  mode  checks  the  slave  triggering  according  to 
the  trigger  window  provided  by  the  overlying  WdgM  instance.  The  system 
© 2016 Vector Informatik GmbH 
Version 1.1.0 
47 
based on template version 5.12.0 

---

Technical Reference MICROSAR WDGIF 
integrator must make sure that the trigger window values configured for WdgM are 
correct! 
 
 
Note 
Manual configuration supports the configuration of a counter increment interval. Hence, 
  it can also be used for asynchronous mode. 
 
 
 
 
Note 
Using  automatic  configuration  for  synchronous  mode  is  not  recommended,  because 
  the resulting reaction time is higher than necessary. 
 
 
6.2.1 
Manual Configuration for Synchronous Mode 
In synchronous mode, the reference cycle and the minimum and maximum expected slave 
triggers are usually configured manually. 
In  order  to  configure  the  State  Combiner  manually  for  synchronous  mode  following 
parameters must be configured in the ECU description: 
>  Set WdgIfUseStateCombiner to true (enable State Combiner). 
>  Set WdgIfStateCombinerUseManualMode to true. 
>  Set  WdgIfStateCombinerReferenceCycle  to  the  expected  number  of  slave 
triggers. 
>  Set  WdgIfStateCombinerSlaveIncrementsMin  to  the  constant  number  of 
expected slave triggers. 
>  Set  WdgIfStateCombinerSlaveIncrementsMax  to  the  constant  number  of 
expected slave triggers as well. 
 
 
Note 
The last three parameters are set for each slave. 
 
 
 
 
 
Note 
WdgIfStateCombinerSlaveIncrementsMin and 
  WdgIfStateCombinerSlaveIncrementsMax must have the same value for 
synchronous mode! 
 
 
Example scenario 1: Assume that the necessary conditions for synchronous mode apply, 
the  master  period  is  20ms  and  the  slave  period  is  20ms.  The  following  configuration  is 
recommended for the State Combiner: 
>  WdgIfUseStateCombiner = true 
>  WdgIfStateCombinerUseManualMode = true 
© 2016 Vector Informatik GmbH 
Version 1.1.0 
48 
based on template version 5.12.0 

---

Technical Reference MICROSAR WDGIF 
>  WdgIfStateCombinerReferenceCycle = 1 
>  WdgIfStateCombinerSlaveIncrementsMin = 1 
>  WdgIfStateCombinerSlaveIncrementsMax = 1 
Example scenario 2: Assume that the necessary conditions for synchronous mode apply, 
the  master  period  is  20ms  and  the  slave  period  is  40ms.  The  following  configuration  is 
recommended for the State Combiner: 
>  WdgIfUseStateCombiner = true 
>  WdgIfStateCombinerUseManualMode = true 
>  WdgIfStateCombinerReferenceCycle = 2 
>  WdgIfStateCombinerSlaveIncrementsMin = 1 
>  WdgIfStateCombinerSlaveIncrementsMax = 1 
Example scenario 3: Assume that the necessary conditions for synchronous mode apply, 
the  master  period  is  30ms  and  the  slave  period  is  10ms.  The  following  configuration  is 
recommended for the State Combiner: 
>  WdgIfUseStateCombiner = true 
>  WdgIfStateCombinerUseManualMode = true 
>  WdgIfStateCombinerReferenceCycle = 1 
>  WdgIfStateCombinerSlaveIncrementsMin = 3 
>  WdgIfStateCombinerSlaveIncrementsMax = 3 
6.2.2 
Automatic and Manual Configuration for Asynchronous Mode 
There are two possible ways of configuring the State Combiner for asynchronous mode – 
it can either be configured to calculate the reference cycle and number of expected slave 
triggers automatically, or these parameters can be configured manually. 
If  the  State  Combiner  is  configured  to  calculate  the  number  of  expected  slave  triggers 
automatically, then the number of expected slave triggers as well as the reference cycle is 
calculated during runtime. The calculation is based on the window start and timeout with 
which  both  master  and  slave  are  being  invoked  by  the  WdgM  main  functions  on  their 
respective cores. Following needs to be configured to enable automatic calculation: 
>  WdgIfUseStateCombiner to true (enable State Combiner) 
>  WdgIfStateCombinerUseManualMode to false 
 
 
Note 
Since the automatic calculation is performed dynamically, the ratio between master and 
  slave periods can be changed during runtime without causing a fault reaction (provided 
the respective window start and timeout with which master and slave are invoked 
change according to the new master and slave periods). 
© 2016 Vector Informatik GmbH 
Version 1.1.0 
49 
based on template version 5.12.0 

---

Technical Reference MICROSAR WDGIF 
If the State Combiner is configured manually for asynchronous mode, then the reference 
cycle and the maximum and the minimum numbers of expected slave triggers are entered 
as part of the configuration. Following needs to be configured: 
>  WdgIfUseStateCombiner to true (enable State Combiner). 
>  WdgIfStateCombinerUseManualMode to true. 
>  WdgIfStateCombinerReferenceCycle to the required value. 
>  WdgIfStateCombinerSlaveIncrementsMin to the required value. 
>  WdgIfStateCombinerSlaveIncrementsMax to the required value. 
 
 
Note 
The last three parameters have to be set for each slave. 
 
 
 
Example scenario 1 – automatic configuration: 
Assume that the necessary conditions for synchronous mode do not apply. The following 
configuration is chosen for the State Combiner: 
>  WdgIfUseStateCombiner = true 
>  WdgIfStateCombinerUseManualMode = false 
The value of the slave trigger counter is expected to rise within every check interval. The 
expected  number  of  counter  increments  is  computed  dynamically  based  on  the  trigger 
window of the slave compared to the trigger window of the master (the WindowStart and 
Timeout parameters with which the master and slave are invoked). The reference cycle is 
calculated as the smallest value that guarantees that at least one counter increment from 
the slave occurs within the check interval. 
Example scenario 2 – manual configuration:  
Assume that the necessary conditions for synchronous mode apply, the master period is 
20ms  and  the  slave  period  is  20ms.  Jitter  for  both  master  and  slave  is  maximum  2ms. 
Following configuration is optimal for the State Combiner: 
>  WdgIfUseStateCombiner = true 
>  WdgIfStateCombinerUseManualMode = true 
>  WdgIfStateCombinerReferenceCycle = 2 
>  WdgIfStateCombinerSlaveIncrementsMin = 1 
>  WdgIfStateCombinerSlaveIncrementsMax = 3 
© 2016 Vector Informatik GmbH 
Version 1.1.0 
50 
based on template version 5.12.0 

---

Technical Reference MICROSAR WDGIF 
7  Glossary and Abbreviations 
7.1 
Glossary 
Term 
Description 
<infix> 
A placeholder with this name is interpreted as follows: 
>  In case of AUTOSAR 4 compatible environment the <infix> 
placeholder consists of the vendor ID and device name string 
of the configured Watchdog driver. 
>  In case of AUTOSAR 3 compatible environment the <infix> 
placeholder consists of the device name string of the 
configured Watchdog driver. 
Check interval 
The duration between two consecutive points in time when the master 
checks a slave trigger counter. It is the reference cycle multiplied by the 
master invocation period. 
Master 
State Combiner instance which is configured to work in master mode. 
Slave 
State Combiner instance which is configured to work in slave mode. 
Master / Slave 
In the WdgM Stack, this is the point in time when the 
invocation 
WdgM_MainFunction of the overlying WdgM is invoked – this main 
function eventually calls the master / slave. 
Reference cycle 
The number of master periods between two consecutive checks of the 
slave by the master. One means that the master checks a slave each 
time the master is invoked; two means that the master checks a slave 
every second time the master is invoked, etc. Note that for each slave the 
reference cycle can be different. See also check interval. 
Slave trigger errors 
They are: 
>  slave invocation omissions, 
>  slave invocation drifting, 
>  too frequent slave invocations and 
>  unscheduled triggers. 
Trigger counter 
A variable in shared memory for each slave which starts from 0 and is 
being incremented by its slave each time the slave is invoked with a 
trigger request. 
Number of slave 
The number of trigger requests of a slave during a given period of time. 
triggers 
Table 7-1   Glossary 
 
 
© 2016 Vector Informatik GmbH 
Version 1.1.0 
51 
based on template version 5.12.0 

---

Technical Reference MICROSAR WDGIF 
7.2 
Abbreviations 
Abbreviation 
Description 
API 
Application Programming Interface 
AUTOSAR 
AUTOSAR (AUTomotive Open System ARchitecture) is a worldwide 
development partnership of car manufacturers, suppliers and other 
companies from the electronics, semiconductor and software industry. 
DEM 
Diagnostic Event Manager 
DET 
Development Error Tracer 
ECU 
Electronic Control Unit 
MCU 
Microcontroller Unit  
Wdg 
Watchdog Driver 
WdgIf 
Watchdog Interface 
WdgM 
Watchdog Manager 
Table 7-2   Abbreviations 
 
© 2016 Vector Informatik GmbH 
Version 1.1.0 
52 
based on template version 5.12.0 

---

Technical Reference MICROSAR WDGIF 
8  Contact 
Visit our website for more information on 
 
>  News 
>  Products 
>  Demo software 
>  Support 
>  Training data 
>  Addresses 
 
www.vector.com 
 
 
© 2016 Vector Informatik GmbH 
Version 1.1.0 
53 
based on template version 5.12.0 

---

Document Outline

• 1 Component History
• 2 Introduction
  • 2.1 Architecture Overview
  • 2.2 Basic Functionality of the WdgIf
• 3 Functional Description
  • 3.1 Features
    • 3.1.1 Deviations
    • 3.1.2 Additions/ Extensions
  • 3.2 Integration with Fully AUTOSAR Compliant Drivers
  • 3.3 Operation in Multi-Core Systems
    • 3.3.1 Independent Watchdog Devices
    • 3.3.2 WdgIf with a State Combiner
      • 3.3.2.1 Checking the Slave Trigger Pattern
      • 3.3.2.2 Operation of the State Combiner
        • 3.3.2.2.1 Synchronous Mode
        • 3.3.2.2.2 Asynchronous Mode
      • 3.3.2.3 Worst Case Delay
      • 3.3.2.4 Worst Case Evaluations
      • 3.3.2.5 Optimal Timing
      • 3.3.2.6 Start-up Phase
      • 3.3.2.7 Changing the Monitoring Period During Runtime
        • 3.3.2.7.1 Changing the Monitoring Period in Synchronous Mode
        • 3.3.2.7.2 Changing the Monitoring Period in Asynchronous Mode
      • 3.3.2.8 Shared Memory
      • 3.3.2.9 Limitations of the State Combiner Implementation
  • 3.4 Memory Sections
    • 3.4.1 Code and Constants
    • 3.4.2 Module Variables
      • 3.4.2.1 Module Variables with MICROSAR Os Gen6 / AUTOSAR Os version 4.0
      • 3.4.2.2 Module Variables with MICROSAR Os Gen7 / AUTOSAR Os version 4.2
  • 3.5 Error Handling
    • 3.5.1 Development Error Reporting
• 4 Integration
  • 4.1.1 Static Files
  • 4.1.2 Dynamic Files
• 5 API Description
  • 5.1 Type Definitions
  • 5.2 State Combiner Type Definitions
  • 5.3 Services provided by WdgIf
    • 5.3.1 WdgIf_SetMode
    • 5.3.2 WdgIf_SetTriggerCondition
    • 5.3.3 WdgIf_SetTriggerWindow
    • 5.3.4 WdgIf_GetVersionInfo
    • 5.3.5 WdgIf_GetTickCounter
  • 5.4 Services used by WdgIf
• 6 Configuration
  • 6.1 Configuration Variants
  • 6.2 Configuring the State Combiner
    • 6.2.1 Manual Configuration for Synchronous Mode
    • 6.2.2 Automatic and Manual Configuration for Asynchronous Mode
• 7 Glossary and Abbreviations
  • 7.1 Glossary
  • 7.2 Abbreviations
• 8 Contact

---