Introduction
The Dem is responsible for processing and storing diagnostic events (both externally visible DTCs and internal events reported by other BSW modules) and associated environmental data. In addition, the Dem provides the fault information data to the Dcm and J1939Dcm (if applicable).
How to Read this Document
Here are some basic hints on how to navigate this document.
API Definitions
The application API of the Dem is usually never called directly. The functions declarations here are given for documentation purposes. Parts of the function signatures are not exposed to the actual caller, and represent an implementation detail.
Nonetheless, this documentation refers to the Dem API directly when describing the different features, as the actual name of the API called by the application is defined by the application itself. Instead of a sentence referring to this fact the underlying Dem function name is mentioned directly.
E.g. If the documentation mentions the API Dem_SetOperationCycleState, a client module would call a service function resembling Rte_Call_<APPLDEFINED>_SetOperationCycleState.
An application is strongly advised to never call the Dem API directly, but to use the service interface instead.
Configuration References
When this text references a configuration parameter or container, the references are given in the format of a navigation path:
- /ModuleDefinition/ContainerDefinition/Definition:
The absolute variant is used for references in a different module. These references start with a slash and the module definition. E.g. /NvM/NvMBlockDescriptor - ContainerDefinition/Definition:
The relative variant is used for references to parameters of the Dem itself. For brevity, the module definition has been omitted.
In both variants, the last definition can be either of type container, parameter or reference. This document does not duplicate the parameter description, so please also refer to the module’s parameter definition file (BSWMD-file) for an exhaustive description of the available configuration parameters.
Architecture Overview
The following figure shows where the Dem is located in the AUTOSAR architecture.
The next figure shows the interfaces to adjacent modules of the Dem. These interfaces are described in chapter 5.2.3.
Functional Description
Features
The features listed in the following tables cover the complete functionality specified for the Dem.
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
For further information of not supported features see also chapter 7.3.1.
Vector Informatik provides further Dem 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:
The following features specified in [1] are not supported:
The following features are provided beyond the AUTOSAR standard:
TMC Extensions
The following features are provided specifically for TMC
TMC Limitations
The following requirements defined by [12] are not implemented by the Dem module
Dem Module Architecture
The Dem is separated logically into multiple interacting software components:
- For each OS partition configured with Dem access, a dedicated DemSatellite service SWC provides the interfaces DiagnosticMonitor (chapter 6.6.1.1.1) and DiagnosticInfo (chapter 6.6.1.1.2).
- For one OS partition, a DemMaster service SWC provides the remainder of the AUTOSAR interfaces.
See also chapter 7.4 for details of the split and limitations of the configuration.
Dem Satellite(s)
A DemSatellite performs de-bouncing locally; this includes counter- and timebased debouncing. Also, the DemSatellite provides access to the MonitorStatus introduced in [1] (4.3.0).
As long as application ports only connect to the local DemSatellite there is no runtime overhead for Dem calls.
Dem Master
The actual event processing like UDS status, storage of environmental data and notification handling is performed on the DemMaster service component. Also, the DemMaster is the source of all configured callbacks or notifications.
Please be aware that while it is possible to call operations on the DemMaster across OS partitions, this can incur additional cost introduced by the RTE to implement the necessary synchronization.
Map the DemMaster to the OS partition from where most accesses originate to minimize this runtime overhead.
Communication constraints
To circumvent expensive general cross-partition communication implemented by the RTE, the Dem uses internal data exchange based on shared memory and atomic compare/exchange instructions.
This requires the following access permissions:
- The DemMaster requires Read/Write access to its own data and that of all DemSatellites.
- Each DemSatellite requires Read/Write access to its own data only, and requires Read access to the data of all other satellites and the DemMaster. Write access to the data of other satellites and the DemMaster must be denied.
This memory mapping requires a customized MemMap.h, please refer to chapter 4.3 for common integration tasks.
Instructions for efficient synchronization are provided by all multi-core platforms. However, due to the lack of a common library an implementation needs to be provided during integration. For details please refer to chapter 4.4.
Initialization
Initialization of the Dem module is a multiple-step process.
First, using the interface Dem_MasterPreInit() from the master partition, the Dem loads a preliminary configuration.
After that the NvM can begin to restore the Dem state from the NvRAM and all satellites can be set to a state of reduced functionality using Dem_SatellitePreInit(). After this step, events assigned to the respective satellite can report monitor results to the Dem using Dem_SetEventStatus(). Those monitor results are internally queued and processed within first main function call.
After the satellites have been pre-initialized and after the NvM has finished the restoration of the NVRAM mirror data, the Dem master can be brought to full function using the interface Dem_MasterInit(), followed by the initialization of the satellites per call of Dem_SatelliteInit(). Additionally, the interface Dem_MasterInit() can be used to reinitialize the master after Dem_Shutdown() was called.
For configurations using a single OS partition, the standard AUTOSAR initialization sequence is still supported. Please refer to [1], Dem_PreInit() (chapter 6.2.5.3) and Dem_Init() (chapter 6.2.5.6) for more information.
Initialization States
After the (re)start of the ECU the Dem is in state “UNINITIALIZED”. In this state the Dem is not operable until the interface Dem_MasterPreInit() was called.
Dem_MasterPreInit() will change the state of the master to “PREINITIALIZED”. The state of each satellite is set to “PREINITIALIZED” by the call of Dem_SatellitePreInit(). Within this state only BSW errors from the respective satellite can be reported via Dem_SetEventStatus() and debounce counters can be reset via Dem_ResetEventDebounceStatus(). Enable conditions are not considered in this phase.
During initialization via Dem_MasterInit() resp. Dem_SatelliteInit()the state of the master resp. satellite is set to “INITIALIZED” and the Dem is fully operable afterwards. In this phase enable conditions are initialized to their configured default state and can take effect.
Dem_Shutdown() will finalize all pending operations in the Dem, deactivate the event processing done by the master and change the state of the master to “SHUTDOWN”. If the master is in state “SHUTDOWN” events can still be reported, as they are handled by the respective satellite.
The function Dem_MasterMainFunction() resp. Dem_SatelliteMainFunction() can be called as long as the master resp. the related satellite is in state “INITIALIZED”.
In case SilentBSW checks are enabled, failing run-time checks will cause the Dem to enter state ‘HALTED_AFTER_ERROR’. Please refer to chapter 3.19.1.2 for more details.
Figure 3-2 provides an overview of the described behavior.
Diagnostic Event Processing
A diagnostic event defines the result of a monitor which can be located in a SWC or a BSW module. These monitors can report an event as a qualified test result by calling Dem_ReportErrorStatus() or Dem_SetEventStatus() with “Failed” or “Passed” or as a pre-qualified test result by using the event de-bouncing with “PreFailed” or “PrePassed”.
In order to use pre-qualified test results the reported event must be configured with a debounce
algorithm. Otherwise (using monitor internal de-bouncing) pre-qualified results will cause a DET report and are ignored.
Event De-bouncing
The Dem implements the mechanisms described below:
Counter Based Algorithm
A monitor must trigger the Dem actively, usually multiple times, before an event will be qualified as passed or failed. Each separate trigger will add (or subtract) a configured step size value to a counter value, and the event will be qualified as ‘failed’ or ‘passed’ once this de-bounce counter reaches the respective configured threshold value.
The configurable thresholds support a range for the de-bounce counter of -32768 … 32767. For external reports its current value will be mapped linearly to the UDS fault detection counter which supports a range of -128 … 127.
If enabled, counter based de-bounced events can de-bounce across multiple power cycles. Therefore the counter value is persisted into non-volatile memory during shutdown of the ECU.
Time Based Algorithm
For events using time based de-bouncing, the application only needs to trigger the Dem once in order to set a qualification direction. The event will be qualified after the configured de-bounce time has elapsed. Multiple triggers for the same event and same qualification direction have no effect.
Each event report results at most in reloading a software timer due to a direction change. Once an event was reported, the timer is stopped by
- A “clear DTC” command
- The restart of the event’s associated “Operation cycle”
- Deactivation of (one of) the event’s associated enable condition
- API Dem_ResetEventStatus()
- API Dem_ResetEventDebounceStatus().
Event de-bouncing via time based algorithm requires comparatively high CPU runtime usage. To alleviate this, the Dem supports both a high resolution timer (a Dem main function call equals a timer tick) and a low resolution timer (e.g. 150ms equals a timer tick). Events which have a de-bounce time greater than 5 seconds will use the low resolution timer per default. Still, software timers are expensive and should be used sparingly.
Monitor internal de-bouncing
If the application implements the de-bouncing algorithm itself, a callback function can be provided, which is used for reporting the current fault detection value to the diagnostics layer.
These functions should not implement logic, since they are called in runtime extensive context.
If monitor internal de-bouncing is configured for an event, its monitor cannot request debouncing
by the Dem (i.e. trigger operation SetEventStatus with monitor results DEM_STATUS_PRE_FAILED or DEM_STATUS_PRE_PASSED). This would also result in a DET report in case development error detection is enabled. The Dem module does not have the necessary information to process these types of monitor results.
Event Reporting
Monitors may report test results either by PortInterface or, in case of a complex device driver or basic software module, by direct C API.
Monitor Status
Every event supports a monitor status information which is updated synchronously with the monitor reports:
- Bit 0 – TestFailed
The bit indicates the last qualified test result (passed or failed) reported by the monitor. - Bit 1 – TestNotCompletedThisOperationCycle
The bit indicates if the monitor has reached a qualified test result (passed or failed) in the current operation cycle.
Event Status
Every event supports a status byte whereas each bit represents different status information. For detailed information please refer to [7]. Calculation and change notification (chapter 3.16) of these bits is performed asynchronously on the Dem main function.
- Bit 0 – TestFailed
The bit indicates the qualified result of the most recent test. - Bit 1 – TestFailedThisOperationCycle
The bit indicates if during the active operation cycle the event was qualified as failed. - Bit 2 – PendingDTC
This bit indicates if during a past or current operation cycle the event has been qualified as failed, and has not tested ‘passed’ for a whole cycle since the failed result was reported. - Bit 3 – ConfirmedDTC
The bit indicates that the event has been detected enough times that it was stored in long term memory. - Bit 4 – TestNotCompletedSinceLastClear
This bit indicates if the event has been qualified (passed or failed) since the fault memory has been cleared. - Bit 5 – TestFailedSinceLastClear
This bit indicates if the event has been qualified as failed since the fault memory has been cleared. - Bit 6 – TestNotCompletedThisOperationCycle
This bit indicates if the event has been qualified (passed or failed) during the active operation cycle. - Bit 7 – WarningIndicatorRequested
The bit indicates if a warning indicator for this event is active.
Event Storage modifying Status Bits
Several UDS status bit transitions depend on successful event storage.
For status bits 2 – PendingDTC, 3 – ConfirmedDTC and 7 – WarningIndicatorRequested there are two alternatives: ‘Stored Only’ and ‘All DTC’ – see Figure 3-3.
For status bit 5 – TestFailedSinceLastClear the alternatives ‘Stored Only’ and ‘All DTC’ are supported as well, along with a third option to select different reset conditions for this bit. Please also see chapter 3.6.4.
When using option ‘Stored Only’, the status bits are only set, if a memory entry for the event could be allocated successfully.
On use of option ‘Stored Only’ status bits 2,3 and 5 are reset, if the event is displaced (see chapter 3.5). Status bit 7 is never reset on displacement of the event.
Due to Autosar standardized naming of configuration options, the settings for these bits are named differently for each bit, please refer to Table 3-6 Configuration of status bit processing for details.
Lightweight Multiple Trips (FailureCycleCounterThreshold)
Enabling the feature for multiple trips (see DemGeneral/DemMultipleTripSupport) will enable the full-fledged support, but at the cost of a non-volatile trip counter per event. The common requirement of up to 2 trips (DemEventFailureCycleCounterThreshold <= 1) can work without this added cost.
In case you want to reduce Dem NVRAM consumption, you can disable the full support for multiple trips, and still have support for up to 2 trips for event confirmation.
Event Displacement
In case all available memory slots are already used up by past events when a new event needs to be entered, the Dem can displace a less important event. This is governed by the following set of rules, in the order of mention:
- Dedicated Aging Counters are repurposed first
- Aged events are displaced before other events
- Lower prioritized events will be displaced by higher prioritized events. This step depends on the configuration of event priorities and is omitted if each event has the same priority.
- Passive events of equal priority (test failed bit is not set) can be displaced if no lower prioritized event can be found. This step can be omitted by configuration.
- An active event of equal priority can be displaced if it has not been tested in the active operation cycle. This step can be omitted by configuration.
If multiple events match, the oldest one is displaced. Age in this context is defined by the point in time the event data was last updated.
If no event matches, an option exists to displace the oldest event whatever its state.
Event Aging
The process of aging resets status bit 3 – ConfirmedDTC when a sufficient amount of time has elapsed so that the cause for the error entry is assumedly not relevant anymore. This is often used as a trigger to also clear stored snapshot or extended data from the event memory.
In addition to the aging process defined in [1] there are further options. The differences are summarized in Table 3-7. Independently from the configured Aging Type, an ongoing aging process is stopped when the event is tested ‘failed’ again.
In all cases the event ages only if it supports aging, and the aging process continues long enough so the events aging counter reaches the defined threshold value.
Aging Target ‘0’
Events aging ‘immediately’ are handled in a special way, depending on the configured aging algorithm.
In general, they age immediately when the aging start condition is reached. For details refer to Table 3-8.
Aging events without memory entry
To implement aging of events, an event requires an aging counter. This counter is by default contained within the event memory entry along with stored additional data. If the confirmed bit is set independently of event storage (see chapter 3.4.4.1) events do not necessarily have the means to age, even if they meet the precondition (e.g. test completed and not tested failed for one operation cycle). The DEM provides two options for events without memory entry to age.
Aging through Reallocation
In this case the Dem module tries to reallocate a free memory entry for the aging event. This event entry is used solely for the purpose of aging the confirmed DTC bit.
Memory Entry Independent Aging
When the option (DemGeneral/ DemSupportAgingForAllDTCs) is enabled, the DEM uses a dedicated NVRAM backed array to store aging counters of all DTCs. This option allows the user to bypass the restriction that only DTCs with a memory entry can age, at the cost of maintaining an additional NVRAM block. Using this option, an ongoing aging process is only stopped due to displacement if the event is unconfirmed.
Aging of Environmental Data
Stored data can optionally be discarded or kept intake once a DTC has completed the aging process and resets its ConfirmedDTC bit.
If the data is kept intact, it is reported to the Dcm in the same way it is reported for active events.
Aging of TestFailedSinceLastClear
The general status bit processing for bit 5 is described in chapter 3.4.3. There is however an additional option to reset this bit when an event ages.
Currently the aging counter value required to reset Bit 5 is the same as for ConfirmedDTC, so there is no way to age it at a later time.
Please refer to the configuration parameter DemGeneral/DemStatusBitHandlingTestFailedSinceLastClear for details.
Aging and Healing
Aging and healing normally happen in parallel. The Dem does not implement safe guards to prevent aging before healing has occurred. This situation is rather unusual and would indicate a mistake in the configuration, or how the cycles are reported to the Dem.
For some use-cases like OBD II, it is supported to only start with the aging process once a configured indicator request has completed healing. In order to achieve consistent behavior across all DTCs, this can be activated also for events not supporting an indicator. Using this option, the Dem only waits for events to heal before aging is started, if the event has the ConfirmedDTC status bit set. If the event needs more than a single passed result to heal, aging starts after healing without an additional trigger.
This aspect of the aging behavior can be selected using the configuration switch DemGeneral/DemAgingAfterHealing.
Operation Cycles
Each event is assigned to an operation cycle, e.g. ignition cycle. An operation cycle can be started and stopped with the function Dem_SetOperationCycleState(). Reporting an event to the Dem is possible only if its corresponding operation cycle is started – otherwise the report will be discarded. In this regard the operation cycle acts as additional enable condition which cannot be circumvented.
The operation cycle also is the basis for the status bits referring to ‘this operation cycle’ (Bit 1 and Bit 6), as well as the calculation of events that may or may not have occurred during the whole cycle, e.g. to calculate the precondition for resetting Bit 2.
Since operation cycle restarts can cause a lot of notification function calls, the actual processing is done asynchronously on the Dem_MainFunction(). As notification for the finished processing, please use InitMonitorForX callbacks.
Persistent Storage of Operation Cycle State
The Dem provides the possibility to restore the state of operation cycles through power down. This feature has its caveats though.
The persisted state of operation cycles is not known in pre-initialization state, since the NvM which controls the non-volatile data relies on a pre-initialized Dem!
Until the Dem is completely initialized all operation cycles are inactive, independently of their stored state. The persisted state only becomes active during Dem_MasterInit(), but this state modification is not counted as flank of the operation cycle state and will not modify the DTC status bytes.
Automatic Operation Cycle Restart
Operation cycles automatically count as enable condition for all related events, meaning that if a cycle is not started, monitor reports are not accepted. During ECU startup, there is no valid way to start an operation cycle by API.
If you select a cycle to be started automatically, it will be treated as ‘started’ during pre-initialization, so event reports are possible.
Additionally, all calculations resulting from an operation cycle restart are done in Dem_MasterInit() – But be aware that all notification functions are skipped, since the initialization status of the RTE is not known at this point.
The DTC status calculation is performed in Dem_MasterInit() ‘as if’ the cycle had started before Dem_MasterPreInit(). E.g. fault detection counters of related DTCs do not reset to zero.
Enable Conditions and Control DTC Setting
Up to 254 enable conditions can be assigned to an event. Only if all assigned enable conditions are fulfilled the respective event reported via Dem_ReportErrorStatus() or Dem_SetEventStatus() will lead to a change of the event status bits and a storage of environmental data. Otherwise the event report will be discarded.
A diagnostic monitor using the RTE interfaces to report events can evaluate the return value of the SetEventStatus operation. In case event reports are discarded, this operation will always return E_NOT_OK. It is not possible to tell the exact reason for the discarded report.
Enable condition states can be set via Dem_SetEnableCondition() respectively by the corresponding port interface operation.
As enabling enable conditions and ControlDTCSetting is deferred to the Dem main function, it is possible to lose enable condition and ControlDTCSetting changes that toggle faster than the cycle time of the Dem main function.
Depending on the configuration, the Dem resets or freezes an ongoing de-bouncing process, when the event’s enable conditions change.
Effects on de-bouncing and FDC
While enable conditions are disabled, de-bouncing is usually stopped as well. The Dem allows configuring whether events continue de-bouncing where they left off, or whether they start from the beginning – or even continue de-bouncing.
The point in time of the reset, being either when the enable conditions are disabled or re-enabled,
is also subject to configuration.
In any case, it is not possible for events to qualify during the time enable conditions (or ControlDTCSetting) are disabled.
Storage Conditions
Up to 255 storage conditions can be assigned to an event. If the assigned storage conditions are not fulfilled, the respective event reported via Dem_SetEventStatus() will change its status byte, but its environmental data and statistical data (e.g. most recent failed event) is not stored or updated.
Also, status bits 2, 3, 5 and 7 will not transition while storage conditions are not fulfilled (depending on configuration options, see chapter 3.4.4.1).
The storage condition state can be set via Dem_SetStorageCondition().
DTC Suppression
AUTOSAR provides two mechanisms to disable, hide or otherwise prevent evaluation of test reports. They differ in the impact of the suppression operation.
This implementation allows calling the event based suppression API before full initialization, and calls by BSW or CDD (i.e. it does not require Rte_Call). Please be advised that this is an extension to [1].
Event Availability
The API Dem_SetEventAvailable() can disconnect the event reporting from event processing. Use this mechanism in case the ECU has fault paths that are supported conditionally, e.g. due to ECU variants.
Unavailable events do not track a status. They cannot confirm, cannot enter the event memory, and attached DTCs are not reported to the outside world, i.e. through Dcm API.
Event reports and the request to suppress the same event do collide. In order to correctly implement suppression, unused DTCs should be suppressed before the monitor in question starts to report test results for it.
DTCs and events already stored in the event memory cannot be made unavailable and the corresponding API call will fail.
For combined events, the DTC will be hidden only after all events attached to the DTC have been set to disabled.
Suppress DTC
The suppression APIs only ‘hide’ DTCs to the outside world, i.e. in general, they do not match any filter and are not reported via Dcm query functions. Requests for a single selected, suppressed DTC respond negatively. Only when filtering all supported DTCs, it can be selected by configuration whether suppressed DTCs shall be reported.
Event processing and storage are processed normally – this means suppressed DTCs can use up memory slots, and enable indicators.
Environmental Data
The Dem supports storage of data with each DTC in form of snapshot records and extended data records.
A Snapshot Record is DTC specific and consists of one or more DIDs (Data Identifiers) which in turn consist of one more data elements. Snapshot Records are collected and stored at a configurable point in time during event confirmation, and often multiple times.
An Extended Data Record is defined globally and consists of one or more data elements. It is typically used for statistic values like the occurrence counter or aging counter that are not frozen at storage time.
The content of data elements can be provided by the application or by the Dem itself.
For application defined data the Dem will request the data using callback functions every time a new value needs to be stored, and supply the stored values to the reading module (e.g. the Dcm). This type of data is comparable to snapshot records in that no current value can be supplied to a reader.
To use internal data provided by the Dem, data elements must be mapped by configuration to the requested statistical value. The Dem will then always supply the current value of the respective statistic to reading modules.
Figure 3-5 provides an example of the described layout.
Storage Trigger
The exact storage trigger to allocate an event memory entry is configured with the option DemGeneral/DemEventMemoryEntryStorageTrigger. It can be configured to allocate event memory entry on triggers like confirmation, fulfillment of FDC storage threshold or transition of PendingDTC or Test Failed status bits. Allocation of an event memory entry is the prerequisite for storage of snapshot records and extended data records.
A failing DTC will (ideally) create the following triggers, in the following order:
- FDC threshold (< qualified failed) exceeded
- FDC qualifies, Bit 0 is set
- DTC Pending, Bit 2 is set
- DTC Confirmed, Bit 3 is set
Although in reality these can easily all occur at the same time.
Snapshot Records
Once an event memory entry is created for the DTC, there are two algorithms determining
when snapshot records are captured. These algorithms can be selected with the option
DemGeneral/DemTypeOfFreezeFrameRecordNumeration.
The first option is the ‘Calculated Snapshot Record’, for which snapshot records are
captured with each passed-failed transition of an event.
The second option is the ‘Configured Snapshot Record’, which allows defining for each
snapshot record in detail when to capture it with the option
DemGeneral/DemFreezeFrameRecNumClass/DemFreezeFrameRecordTrigger.
It can also be configured if its contents should be updated with each new trigger with the
option DemGeneral/DemFreezeFrameRecNumClass/DemFreezeFrameRecordUpdate.
Extended Data Records
Extended data records can be configured to be stored either at trigger ‘Failed’, ‘FDC
Threshold’, ‘Passed’ or ‘Confirmed’ via DemGeneral/DemExtendedDataRecordClass/
DemExtendedDataRecordTrigger.
In most cases, extended data records are available when an event has a memory. In
addition, extended data records, which consists only of statistical data which by its nature
is available at any time (e.g. Priority, Significance, current FDC) can be configured to be
read out independently of an event memory entry through the parameter
DemGeneral/DemExtendedDataVisibility.
Through the option DemGeneral/DemExtendedDataRecordClass/
DemExtendedDataRecordUpdate, it can be specified whether an extended data record
should be updated with re-occurrence of the corresponding trigger.
Storage Trigger ‘Passed’
The storage of extended data record with trigger ‘Passed’ requires a ‘qualified Passed’
(either by debouncing or through a ‘Passed’ status report) that resets the TestFailed bit
from 1 to 0.
Resetting the TestFailed bit via API Dem_ResetEventStatus() or option
DemGeneral/DemResetTestFailedOnOperationCycleStart does not store the extended
data record.
Storage Trigger ‘FDC Threshold’
The storage of a snapshot or extended data record prior to event qualification can be
realized by Dem internal or monitor internal debouncing. For an event using a Dem
internal debouncing algorithm threshold values need to be configured. In case of monitor
internal debouncing, calling API Dem_SetEventStatus() or Dem_ReportErrorStatus() with
monitor status ‘FDC Threshold Reached’ triggers the Dem to store the snapshot or
extended data record.
Internal Data Elements
The Dem provides access to the following values by means of an internal data element.
Internal data is usually not frozen in the primary memory, but rather the current value is
reported.
Aging counter
Available both in positive direction, counting up from 0 (event is not aging) up to the
configured threshold value; and in reverse counting down to 0.
Aged counter
Counts how often a DTC has aged since the DTC was cleared the last time. The usage of
this feature requires the maintaining of an additional NVRAM block (see 4.5.1 NVRAM
Demand).
Healing counter
Available both in positive direction, counting up from 0 (healing not started), latching at
255; and in reverse counting down from the healing threshold (healing not started) to 0.
The counter is incremented resp. decremented as soon as the healing conditions are
fulfilled (at the end of a ‘passed’ tested operation cycle without failed result), irrespective of
the status of the ‘ConfirmedDTC ‘ or ‘WarningIndicatorRequested’ status bit.
The up-counting data element corresponds to ‘Cycles Tested Since Last Failed’.
Both data elements are also calculated for events without indicator.
Overflow indication:
Indicates if the event’s memory destination has overflown.
Event priority:
Is set to the configured priority value of the event.
Significance:
Is set to the configured event significance value. Occurrence is 0, Fault is 1.
Root cause EventId
The event id that caused the storage/update of the environmental data. Can be used in
context of the feature combined events to store the root cause event id.
OBD DTC
The OBD DTC for the event id that caused the storage/update of the environmental data. If
no OBD DTC is configured the returned value will be 0.
OBD Ratio
The event specific numerator and denominator values if the event has a ratio attached
(see [10]). If no OBD is supported or the event does not support a ratio, the values are
reported as 0. Ratios for combined events are also reported as 0.
To support ratios in extended data records for combined events, use a callback with
EventId, and without NV storage instead. In this callback you can calculate the combined
ratio.
Fault Detection Counter statistics
The current fault detection counter can always map. For internally de-bounced events, the
maximum value per operation cycle, and the maximum value since last clear are available
as well.
Occurrence counter
Counts the number of passed-failed transitions since an event has been stored. This
counter is available in 8bit and 16bit variants.
Operation cycle counters
> Counter of cycles tested failed
> Counter of cycles tested failed consecutively
> Counter of cycles tested failed consecutively latching at the threshold needed for DTC
confirmation (‘Fault Pending Counter’)
> Counter of cycles completed since first failed
> Counter of cycles completed since last failed
> Counter of cycles completed and tested since first failed
> Counter of cycles completed and tested since last failed
External Data Elements
Data is collected through required port prototypes and needs to be mapped to the data
provider during Rte configuration. Please note that each data element has its own port
interface and port prototype. It is not supported to collect a variety of DIDs or data signals
through a shared callback function by AUTOSAR design.
As a vendor specific extension, the MICROSAR Dem module supports Client/Server data
callbacks that also pass the EventId to the application. This allows scenarios not possible
with a standard Dem:
Application managed data storage: e.g. connecting the Dem to legacy applications that
already store (parts of) the environment data.
Event specific data contents: e.g. storing root cause dependent data.
NVRAM storage
The usual AUTOSAR Dem will store all data collected from the application in NVRAM.
For such data elements, data sampling is always processed on the Dem cyclic function.
Queries (e.g. through Dcm UDS diagnostic services) always return the frozen value.
As an extension to AUTOSAR, the Dem also allows to configure data elements to return
‘live’ data. This is useful especially to support statistics data that is not already covered by
the Dem internal data elements.
When data elements are configured not to be stored in NVRAM, the data is requested
every time a query is processed. Their implementation should be reentrant and fast to
allow diagnostic responses to complete in time.
Confirmed Time Series Snapshot Records
The purpose of confirmed time series snapshot records is to access vehicle data for a
period in time before and after the confirmation of a malfunction.
DID data is collected periodically at fixed time intervals. Two different time intervals are
supported: a normal rate and fast rate.
If an event uses time series snapshot records, the configured number of past samples is
stored at confirmation of the event. Following confirmation, the configured number of future
samples is stored once they have been sampled.
The samples can be requested via record numbers x1,…,xp,xp+1,…,xp+f, where p is the
configured number of past samples, f the configured number of future samples, p + f <=
32. For the normal rate numeration starts with 0x30, for the fast rate with 0x10.
Time series snapshot records consist of the same DIDs as the ‘normal’ confirmed
snapshot record. The samples for the normal and fast rate are collected and stored
independently from each other, however fast rate samples cannot be used without normal
rate samples.
It is not recommended to use event specific data elements in DIDs because time series
snapshot data is collected globally for all events and in this case the records won’t contain
reasonable data for a single event. If internal data elements are used in DIDs, the records
will at best contain the current data at the time of the diagnostic service request. If no
memory entry is available for the event, they will be padded with 0xff.
The number of events for which time series records can be stored at the same time is
limited. If the storage capacity is exhausted the same displacement strategy is used for
time series memory slots as for primary memory slots.
In case a DTC is removed from primary memory due to aging, a clear request or
displacement, the time series snapshot records for this DTC are also removed.
Global Snapshot Record
The global snapshot record provides same functionality as ‘Configured/ Calculated
snapshot records’ except that it has a separate, globally defined DID list (see configuration
parameter DemGeneral/DemGlobalFreezeFrame) which applies for all DTCs.
Global snapshot records are stored at DTC confirmation. Update of already stored global
snapshot records is currently not supported.
Freeze Frame Pre-Storage
The environmental data associated with a DTC is collected when the DTC storage is
processed on the Dem task function. The delay between the event report and the data
collection can be a problem if fast changing data needs to be captured. In other use-cases
the DTC is supposed to store a snapshot of the system state some time before the event
qualification finishes.
Using Dem_PrestoreFreezeFrame() a monitor can request immediate data capture. If
successful, this snapshot is used as the data source if the DTC is stored to the event
memory later on.
The Dem captures the following data, if relevant:
A UDS snapshot record
A OBD freeze frame
J1939 freeze frame and expanded freeze frame
A Global snapshot record
The Dem can only pre-store a limited number of events (see configuration parameter
DemGeneral/DemMaxNumberPrestoredFF). Once the provided space is exhausted
subsequent pre-storage requests will fail until one or more of them are freed. It is always
possible to refresh a pre-stored data set already allocated to an event.
Pre-Stored data is not preserved after shutdown, and will be discarded automatically once
it is used or after a qualified test result has been processed for the respective event. Also
see Dem_ClearPrestoredFreezeFrame() for a way to explicitly discard stale data.
Multi-partition setup
Freeze Frame Pre-Storage can be used in multiple-partition setups. The APIs
Dem_PrestoreFreezeFrame() and Dem_ClearPrestoredFreezeFrame() are provided on all
satellites. For satellites running on a partition other than Dem master, pre-store requests
are processed asynchronously on Dem’s main function. Asynchronous pre-storage
requests are always accepted and give no feedback whether a freeze frame pre-storage
slot was acquired or not.
For satellites running on the master’s partition, pre-store requests are still processed
synchronously.
Combined Events
It is possible to combine the results of multiple monitors to a single DTC. This feature is
referred to as ‘Combined Events’ in this document.
Monitors report events as usual, events are de-bounced individually, and for each event
the Dem keeps track of its individual status byte. Only when a DTC status is required there
is a visible difference.
Configuration
Currently the configuration format allows too much freedom in configuration due to the
multiple combination types. For Type 1 combination the following restrictions apply:
All events mapped to the same DTC must have identical environmental data
(extended records, number and content of snapshot records etc.
All events mapped to the same DTC must use the same cycles (operation, failing,
healing and aging cycles)
All events mapped to the same DTC must use the same destination, significance,
priority, the same setting for ‘aging allowed’ and the same significance.
All events mapped to the same DTC must reference the same readiness group (see
[10] ).
The behavior with mixed settings is undefined and not supported by this implementation.
Event Reporting
Since version 13.00.00 there is no difference between combined events and normal
events. Refer to 3.4.2 for additional information.
DTC Status
If event combination is used, the DTC status does not correspond to the event status
directly. Instead, the DTC status is derived from the status of multiple events.
As defined by Autosar (see [1]) this combined status is calculated according to Table 3-9.
Basically, the DTC status is an OR combination of all events, with the resulting status byte
modified by an additional combination term. This is done to make sure that a failed result
will also reset the ‘test not completed’ bits, even if not all contributing monitors have
completed their test cycle.
Environmental Data Update
Environment data and statistics are calculated based on the DTC status, not the event
status of contributing events.
Example: The occurrence counter, if configured, is not incremented with each failing
monitor. Instead, the occurrence counter is incremented each time Bit0 of the combined
DTC transitions 0 → 1.
A failed monitor result might therefore not result in an update of event data (nor an event
data changed notification). This behavior is intentional.
Aging
A combined DTC starts to age once the conditions discussed in chapter 3.6 are fulfilled for
each event, e.g. once all monitors have reported a ‘passed’ result.
Clear DTC
If a request to clear a combined DTC is received, all monitors that define a ‘clear DTC
allowed’ callback will be notified by the Dem and have a chance to prevent the clear
operation. If a single monitor disallows the clear operation, the DTC will be left in the event
memory.
Non-Volatile Data Management
The Dem uses the standard AUTOSAR data management facilities provided by the NvM
module.
NvM Interaction
If immediate data writes are enabled, the NvM needs to support API configuration class 2.
Otherwise the APIs provided by configuration class 1 are sufficient for Dem operation.
If you do not use an AUTOSAR NvM module, you have to provide a compatible
replacement in order to use features related to non-volatile data management. The NvM
module needs to implement at least the functionality described in chapter 4.5 NvM
Integration.
NVRAM Write Frequency
The Dem is designed to trigger as few NVRAM writes as possible. Thereto only the data
which typically changes infrequently is stored during ECU runtime. The following table will
give you an overview of the NVRAM write frequency.
Immediate Non-volatile Storage Limit
It is possible to limit the number of immediate NVRAM write accesses by using the
configuration parameter DemGeneral/DemImmediateNvStorageLimit.
Data Recovery
As the Dem uses multiple NVRAM blocks to persist its data (refer to 4.5), it might happen
that correlating data becomes inconsistent due to a power loss or an NVRAM error. To
avoid restoring to an undefined state, during initialization some errors are detected and
corrected, as follows.
> Duplicate entries in a memory are resolved by removing the older entry.
> Stored-Only/Aging status bits are reset if the respective event is not stored, or aged.
> Depending on aging behavior the status bits TestFailed, PendingDTC,
TestFailedThisOperationCycle and WarningIndicatorRequested, are reset for currently
aging events.
> Reset status bit TestFailedThisOperationCycle if both TestFailedThisOperationCycle
and TestNotCompletedThisOperationCycle are set.
> Reset status bit TestNotCompletedSinceLastClear if both TestFailedSincleLastClear
and TestNotCompletedSinceLastClear are set.
> De-bounce counters are reset if they exceed the configured threshold, or the
TestFailed bit does not match a reached threshold (only relevant if de-bounce counters
are stored in NVRAM).
> Stored Events have their status bit corrected if:
> Events are stored when they reach an fault detection counter limit and if
> A consecutive failed cycle counter is supported, and has a value > 0, status bits
PendingDTC and TestFailedSincleLastClear are set. If that counter also exceeds
the failure cycle counter threshold, the ConfirmedDTC status bit is set.
> An occurrence counter is supported and has a value > 0, then status bit
TestFailedSincleLastClear is set.
> Events are stored with other triggers
> The status bit TestFailedSincleLastClear is set.
> If a consecutive failed cycle counter is supported, and has a value > 0, the status bit
PendingDTC is set. If that counter also exceeds the failure cycle counter threshold,
the status bit ConfirmedDTC is set.
> If the event has a failure cycle counter threshold of 0, the status bit ConfirmedDTC
is set.
> If events are stored with trigger ConfirmedDTC, status bit ConfirmedDTC is set.
> If a combined event is stored, but the EventId in NVRAM is not the 'master' EventId for
that combination group, the entry is discarded. This happens due to an integration
error, so also a DET error (inconsistent state) will be set.
> If the event has no warning indicator configured but the status bit
WarningIndicatorRequested is set, then the status bit WarningIndicatorRequested is
reset.
> If memory entry independent aging is enabled, the aging counter of all DTCs which are
not confirmed and do not have a memory entry are invalidated.
Diagnostic Interfaces
To provide the data maintained by the Dem to an external tester the Dem supports
interfaces to the Dcm which are described in chapter 6.2.8.
Please note, these API are intended for use by the Dcm module exclusively and may not
be safe to use otherwise. In case a replacement for the Dcm module has to be
implemented, we politely refer to the Autosar Dcm specification [3], and do not elaborate
on the details within the context of this document.
Notifications
The Dem supports several configurable global and specific event or DTC related
notification functions which will be described in the following. For details please refer to
chapter 6.5.1.
Notification functions will only be called, if the Dem is fully initialized.
Monitor Status Changed
These are notifications for a monitor status change. With the given event ID the receiver is
able to identify what has changed.
> General notification:
This callback function is called from Dem for each event on monitor status change.
> FiM notification:
This callback function is called from Dem for each event on monitor status change.
Dependent on the given state the FiM is able to derive the new fault inhibition state.
Event Status Changed
These are notifications for an event status change independent of the DTC status
availability mask. With the given old and new status, the receiver is able to identify what
has changed.
> General notification:
This callback function is called from Dem for each event on event status change.
> Event specific notifications:
Each event may have one or more of these callback functions which are called only if
the respective event status has changed.
> FiM notification:
This callback function is called for each event on event status change. Dependent on
the given state the FiM is able to derive the new fault inhibition state. In contrast to the
other Event Status Changed callbacks, the FiM is also notified about status changes
resulting from disconnecting or reconnecting the event via API
Dem_SetEventAvailable() (cf. chapter 3.10.1).
> Dlt notification:
This callback function is called for each event on event status change.
DTC Status Changed
These are notifications for a DTC status change. The DTC status availability mask is taken
into account, so status bits which are not supported will not cause a notification. It is also
possible that a changed event status does not change the resulting status of a combined
DTC.
> Global notifications:
The configuration can define one or more of these callback functions which are called
only if the respective DTC status has changed.
> Dcm notification:
This callback function is called for each DTC status change. Dependent on the given
state the Dcm is able to decide if a ROE message shall be sent.
Event Data Changed
These notifications will be called from Dem if the data related to an event has changed.
> General notification:
This is a single callback function which is called for each event on data change.
> Event specific notification:
Each event may have one callback function which is called on event data change.
Monitor Re-Initialization
These notifications are called from Dem, to signal to diagnostic monitors that a new test
result is now requested. This can happen due to clearing the fault memory, the start of a
new operation cycle, or the re-enabling of previously disabled DTC settings or enable
conditions
The set of notification calls is fully customizable in the configuration.
> Event specific notification:
Each event may have one callback function which is called for the reasons mentioned
above.
> Function specific notifications:
Each event may have one or more of this callback functions which is called for the
reasons mentioned above.
For combined events, this callback is notified for each event if they are re-enabled by
enable conditions.
ClearDTC Notification
These notifications will be called from the Dem task function either before of after
processing the clear request. This is configurable per notification.
> Before a clear request is started, i.e. before any DTC is modified or a ClearAllowed
callbacks is invoked.
> After a clear request has finished. This is either after all DTCs have been reset in
RAM, or after the cleared NV information was persisted by the NvM. The notification
will be triggered before Dcm can send a response.
ControlDTCSetting Changed
This notification function is called when ControlDTCSetting is disabled or enabled.
Indicators
An event can be configured to have one or more indicators assigned. An indicator is
reported active if at least one assigned event requests it, and cleared when all events
assigned to it have revoked their warning indicator request (i.e. by healing or diagnostic
service ClearDtc).
The indicator status is set always with event confirmation (set condition of bit 3), and reset
after the configured number of operation cycles during which the event was tested, but not
tested failed.
An event’s warning indicator request status is reported in bit 7 of the UDS status byte.
User Controlled WarningIndicatorRequest
Use cases that demand setting of the UDS Bit 7 (WarningIndicatorRequest) differently
from the normal indicator handling can be met using the operation SetWIRStatus (see
chapter 6.6.1.1.9).
Examples include resetting the WIR bit only with the next power cycle after the indicator
status has healed, or setting it with the first failed result instead of the ‘confirmedDTC’ bit.
This interface also allows controlling Bit7 of a BSW error. There is only a SWC API
available to control the WIR status bit of BSW errors, so a SWC module has to be used for
this task in all cases.
To calculate the visible status of Bit 7, the ‘normal’ monitor WIR request is logically OR’ed
to the user controlled state as depicted in Figure 3-6.
Interface to the Runtime Environment
The Dem interacts with the application through the Rte and defined port interfaces (see
chapter 6.6).
There are no statically defined callouts that need to be implemented by the application. All
notifications and callouts are set up during configuration.
This is why the Dem software component description file (Dem_swc.arxml) is generated
based on the configuration.
Error Handling
Development Error Reporting
By default, development errors are reported to the Det using the service
Det_ReportError() as specified in [2], if development error reporting is enabled (i.e.
pre-compile parameter Dem_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 Det_ReportError().
The reported Dem ID is 54.
The reported service IDs identify the services which are described in 6.2. The following
table presents the service IDs and the related services:
Table 3-12 presents the service IDs of APIs not defined by AUTOSAR, the related services
and corresponding errors:
The errors reported to Det are described in the following table:
Parameter Checking
AUTOSAR requires that API functions check the validity of their parameters. These checks
are for development error reporting and are en-/disabled together with development error
reporting.
SilentBSW run-time checks
The Dem module provides several run-time checks to prevent memory corruption caused
by inconsistent NV data. These checks are active only when enabled by configuration.
Most of the Dem state is preserved in NV memory, so inconsistencies introduced into the
NV state would accumulate. The result would be misbehavior at a much later time, e.g.
multiple power cycles after the actual error occurred. To prevent this, the Dem will enter an
error state once a run-time check fails. In this error state, most API functions will return an
error code and return immediately without effect.
To check for the operational state of the Dem module, you have access to the global
variables Dem_LineOfRuntimeError and Dem_FileOfRuntimeError.
Dem_LineOfRuntimeError will be set to 0 during normal operation. If a run-time check
fails, Dem_LineOfRuntimeError resp. Dem_FileOfRuntimeError will be set to the code
line resp. file name on which the error had occurred. In addition, a DET error is reported,
assuming DET reporting is enabled by configuration.
The only way to recover from the Dem error state is an ECU reset.
Production Code Error Reporting
The Dem does not report any production code related errors.
Production code errors in general are errors which shall be saved through the Dem by
definition. Errors of Dem itself occurring during normal operation are not saved as DTC.
J1939
In general the SAE J1939 communication protocol was developed for heavy-duty
environments but is also applicable for communication networks in light- and medium-duty
on-road and off-road vehicles.
J1939 does not describe how the fault memory shall behave but how to report the faults
and their related data.
With the interface described in chapter 6.2.9 the following diagnostic messages can be
supported:
J1939 Freeze Frame and J1939 Expanded Freeze Frame
With J1939 enabled, the Dem supports two globally defined J1939 specific freezes in
addition to the environmental data described in chapter 3.11. Each DTC can be configured
individually to support freeze frame and/or expanded freeze frame, or none.
The J1939 (expanded) freeze frame data is stored when the DTC becomes active
(ConfirmedDTC ➔ 1) and is not updated if the DTC reoccurs.
These freeze frames are stored in addition to any configured ‘standard’ freeze frames but
they are not mapped into a UDS snapshot record.
Indicators
In addition to the ‘normal’ indicators (refer to 3.16.7) a J1939 related DTC may support up
to one of the J1939 specific indicators listed below.
> Red Stop Lamp (RSL)
> Amber Warning Lamp (AWL)
> Protect Lamp (PL)
These indicators use different behavior settings, as required for J1939. These settings are
valid for the indicators mentioned above:
> Continuous
> Fast Flash
> Slow Flash
Differently from the ‘normal’ AUTOSAR indicators, Dem_GetIndicatorStatus() returns a
prioritized result if multiple events request the same indicator with different behavior. E.g.
the PL is triggered at the same time as “Continuous” and “Fast Flash”, the behavior is
indicated as “Continuous”.
DTC and event suppression (refer to chapter 3.10.2) with DTC format set to J1939 the
configured indicator is not applied to the ECU indicator state. I.e. the API
Dem_GetIndicatorStatus() will return the same result whether DTCs are suppressed or
not. To match this behavior, the network management node ID related indicator status also
reports the indicator state of suppressed DTCs.
Clear DTC
In contrast to the clear process defined by UDS which provides the DTC itself or the group
of DTCs that shall be cleared, the J1939 Clear DTC command provides the DTC status
that must match the available J1939 DTCs to be cleared.
DTCs with the following DTC status can be cleared:
Service Only DTCs
Service Only diagnostic trouble codes are DTCs that do not use an indicator and are
stored in secondary memory. These DTCs are accessed by DMs 53-55.
Clear DTC APIs
The clear DTC operations are implemented in full accordance with [1].
Please be aware that the <xxx>ClearDTC interfaces start an asynchronous clear process.
While one clear operation is in progress, clear requests from different clients receive a
DEM_CLEAR_BUSY response (see chapters 6.2.6.28 and 6.2.9.1 for details).
References
MICROSAR Diagnostic Event Manager Technical Reference (Version 17.4.0)
标签：status,DTC,Event,Manager,Dem,events,data,event From： https://blog.csdn.net/erroror/article/details/144605835