What is Diagnostics?
When vehicle or other engine-driven machinery break down, In the garage, an automotive technician must be able to:- Identify the problem.
- Root cause the fault
- Fix the problem
Fix the problem is called "Repair".
when the vehicle functions or vehicle components are working properly as its defined then "Normal state", if not then "Abnormal state".
There are two types of diagnostics such as Off-Board Diagnostics and On-Board Diagnostics.
- Off-Board Diagnostics: Diagnosis is done when the vehicle is at rest in a garage by using car diagnosis tools. it covers the vehicle ECU errors other than emission related errors. several protocol standards are defined such as UDS or KWP.
- Vehicle components like ECU functions, sensors or any HW's are continuously checking the status, if it is finds any mismatch then it will stores an errors in the form of DTC. DTCs are stored in EEPROM and retrieved during the vehicle diagnostic testing tool.
- errors are evaluated using debounce algorithm methods
- On-Board Diagnostics: Diagnosis is done when the vehicle is moving and also it is checking the errors of emission related.
- Tests are being conducted while the vehicle is on the road.
- Test results can be seen on vehicle's dashboard in the form of MIL (Malfunction Indicator Light). Drivers are alerted by MIL on the dashboard.
- Each emission-relevant ECU must therefore support the OBD diagnostic. If exhaust-related errors occur (for example, a misfire), they are stored in the fault memory of the ECU and the driver is warned by an indicator, the so-called MIL (malfunction indicator lamp). Using an OBD diagnostic tester, the stored DTC (diagnostic trouble code) can later be read and analyzed.
- DCM(Diagnostic communication Manager)
- DEM (Diagnostic Event Manager)
- FIM(Function Inhibition Manager)
- DET(Development Error Tracer)
In this article, we will discuss DCM module configuration, DID implementation, DEM configuration and DTC implementation.
DCM
The DCM module can be subdivided into three sub modules like Diagnostic Session Layer (DSL), Diagnostic Service Dispatcher (DSD) and Diagnostic Service Processing (DSP).
Figure : Interaction between submodules in the DCM
- Diagnostic Session Layer (DSL): DSL communicates with PduR module, accepts incoming diagnostic request from PduR and sends request to DSD sub module. Receives response from DSD sub module and sends to PduR.
- Diagnostic Service Dispatcher (DSD) : DSD sub module receives incoming diagnostic request by DSL module. DSD validates requested service and sends request to DSP sub module. Also gathers response and sends to DSL sub-module.
- Diagnostic Service Processor (DSP) : DSP receives service request from DSD sub module, performs check and executes a particular action based on request (Acquire data or execute required function in DEM or SWCs) and assembles response and sends to DSD.
DCM configuration Link : MICROSAR Diagnostic Communication Manager
DSD
- DcmDsd: These parameters configure the Diagnostic Service Dispatcher submodule
- DcmDsdSidTabId: This container contains the configuration (DSD parameters) for a Service Identifier Table.
- DcmDsdService: This container contains the configuration (DSD parameters) for a Service.
DSL
- DcmDsl: These parameters configure the Diagnostic Session Layer submodule. following containers need to be configured DcmDslBuffer, DcmDslCallbackDCMRequestService, DcmDslServiceRequestManufacturerNotification, DcmDslDiagResp and DcmDslProtocol.
- DcmDslBuffer :Size of the diagnostic buffer in bytes.
- DcmDslDiagResp: This container contains the configuration of the automatic requestCorrectlyReceivedResponsePending response management in the Dcm.
- DcmDslProtocol: This container contains the configurations of the diagnostic protocols used in DCM.
- DcmDslConnection: This container contains the configuration of a communication channel for one particular protocol. Note that it is allowed to communicate with multiple testers, therefore multiple connections may be configured for a protocol.
DSP
- DcmDsp: These parameters apply to Diagnostic Service Processing. There will always be one set of these parameters per DCM.
- DcmDsp container contains the huge configuration parameter sets. this container contains DIDs and RIDs. this module contains many submodules for DID and RID.
DID Configuration
First step: Enable/Disable parameter "DcmDspDataFixedLength" in DcmDspDataInfos. mention data is fixed length or not.
Second step: which kind of interface shall be used to access the data like client-server, sender-receiver or by function in DcmDspData. function requests to the application a data value of a DID
Third step: configure "DcmDspDidInfo" container. The DID Info determines how a DID can be accessed. A DID can have read, write and control access. For each access type , security levels and sessions.
Final step: a DID has a signal which is used to define the data associated with the DID. The signal references a DcmDspData container.
for RID we need to follow the same steps as of DID.
Other configurations will done using AUTOSAR DCM spec.
Create server port in the Application and connect the client-server port.
Note: To crate server port follow the following steps
Read DID : In this type, Fill the Data variable with proper information.
Prototype: DataServices_DID_F190_VehicleIdentificationNumber_VehicleIdentificationNumber_0_0_ReadData(Dcm_OpStatusType OpStatus, P2VAR(uint8, AUTOMATIC, RTE_<SWC_Name>_APPL_VAR) Data)
In the below example reading vehcileIdentification number which is stored in the Nvm.
memcpy(Data, Nvm_Vin17, 17);
Write DID: In this type, whatever the value in variable "data" copy to global value or protocol variable.
Std_ReturnType DataServices_DID_F190_VehicleIdentificationNumber_VehicleIdentificationNumber_0_0_WriteData(const uint8 *Data, Dcm_OpStatusType OpStatus, Dcm_NegativeResponseCodeType *ErrorCode)
In the below example writing vehcileIdentification number from user to the memory(NVM) and also updating the NRC in the error code.
memcpy(vin, Data, 17);
IO control DID having following possibilities
The Diagnostic Event Manager (Dem) handles and stores the events detected by diagnostic monitors in both Software Components (SW-Cs) and Basic software (BSW) modules. The stored event information is available via an interface to other BSW modules or SW-Cs
DemConfigSet is the container where diagnostic events and DTCs are added.
for RID we need to follow the same steps as of DID.
Other configurations will done using AUTOSAR DCM spec.
DID Implementation
Note: Once the DID is configured in the Configurator tool (vector Davinci Configurator Pro), It will automatically create Client port in the Configurator tool.Create server port in the Application and connect the client-server port.
Note: To crate server port follow the following steps
- Create a SWC for diagnostic or select any application component already created
- Create a Server port with same parameters of Client port
- Create a runnable and Trigger the runnable on client call invocation.
Read DID : In this type, Fill the Data variable with proper information.
Prototype: DataServices_DID_F190_VehicleIdentificationNumber_VehicleIdentificationNumber_0_0_ReadData(Dcm_OpStatusType OpStatus, P2VAR(uint8, AUTOMATIC, RTE_<SWC_Name>_APPL_VAR) Data)
In the below example reading vehcileIdentification number which is stored in the Nvm.
memcpy(Data, Nvm_Vin17, 17);
Write DID: In this type, whatever the value in variable "data" copy to global value or protocol variable.
Std_ReturnType DataServices_DID_F190_VehicleIdentificationNumber_VehicleIdentificationNumber_0_0_WriteData(const uint8 *Data, Dcm_OpStatusType OpStatus, Dcm_NegativeResponseCodeType *ErrorCode)
In the below example writing vehcileIdentification number from user to the memory(NVM) and also updating the NRC in the error code.
memcpy(vin, Data, 17);
IO control DID having following possibilities
- FreezeCurrentState: This function requests to the application to freeze the current state of an IOControl.
- ShortTermAdjustment: This function requests to the application to adjust the IO signal.
- ReturnControlToECU: This function requests to the application to return control to ECU of an IOControl.
- ResetToDefault: This function requests to the application to reset an IOControl to default value.
DEM Basics
The Diagnostic Event Manager (Dem) handles and stores the events detected by diagnostic monitors in both Software Components (SW-Cs) and Basic software (BSW) modules. The stored event information is available via an interface to other BSW modules or SW-Cs
DEM Glossary
How DEM working
- The Dem module shall represent each Diagnostic Event by an EventId and the related EventName.
- Monitor function will report a status of event to DEM.
- Event id is assigned to an event. This event id is unique per event.
- Diagnostic trouble code (DTC) is associated with an event. When event is reported as passed or failed, status of DTC changes.
- The Dem module shall initialize the occurrence counter with the value one if the related event is entered in the respective event memory.
- The Dem module shall calculate the fault detection counter (- 128 to +127 according to UDS) based on the value and range of the internal debounce counter to map the internal counter values linearly to the external values.
- The Dem module shall provide a configuration parameter DemDebounceCounterBasedSupport to enable or disable the Dem-internal counter based debouncing.
- [SWS_Dem_00418] The Dem module shall increment the internal debounce counter with its configured step-size (refer to DemDebounceCounterIncrementStepSize), when the monitor reports DEM_EVENT_STATUS_PREFAILED.
- [SWS_Dem_00419] d The Dem module shall decrement the internal debounce counter with its configured step-size (refer to DemDebounceCounterDecrementStepSize), when the monitor reports DEM_EVENT_STATUS_PREPASSED.
- [SWS_Dem_00420] If the monitor reports DEM_EVENT_STATUS_FAILED, the Dem module shall set the internal debounce counter value to its configured threshold being the failed criteria.
- [SWS_Dem_00421] d If the monitor reports DEM_EVENT_STATUS_PASSED, the Dem module shall set the internal debounce counter value to its configured threshold being the passed criteria.
DEM Configuration
The Dem module consists of two main configuration containers, DemGeneral and DemConfigSet. DemGeneral holds the general settings for the Dem module, such as buffer setting, freeze frame data storage trigger, etc. DemGeneral is also where freeze frames, extended data, DIDs, operation cycles, NvRam blocks, etc. are added.DemConfigSet is the container where diagnostic events and DTCs are added.
DemGeneral
DemConfigSet ---DemDTCClass
DemConfigSet ---DemEventParameters
Relevant errors are reported either from Application Layer (resp. SW-C) or Basic Software Modules (BSWM).
BSWs report the new status of the event with the Dem_ReportErrorStatus API.
SWCs report the new status of the event with the Dem_SetEventStatus API (through the RTE)
DemConfigSet ---DemEventParameters ---DemDebounceAlgorithmClass
BSWs report the new status of the event with the Dem_ReportErrorStatus API.
SWCs report the new status of the event with the Dem_SetEventStatus API (through the RTE)
DemConfigSet ---DemEventParameters ---DemDebounceAlgorithmClass
DTC Implementation
A Failure Record (also referred to as a “Snapshot” by ISO 14229-1 and “Freeze Frame” by AUTOSAR and SAE J1979) is a block of memory containing the vehicle operating conditions stored at the time when a DTC algorithm reports a test failed result. The data stored in a failure record provides the operating context for the DTC and is intended to allow for re-creation of the system operating conditions under which the fault occurred. The enhanced failure record strategy splits the failure record into two parts, the environmental data / vehicle operating conditions stored in a central repository upon receipt of the DTC Triggered message and the snapshot portion retrieved from the ECU that set the DTC. The two parts of the record are correlated by the presence, in each record, of the DTC + FTB combination that caused the record to be stored, the source of the DTC, and the timestamp of when the event occurred.if we need to implement DTC then we should know the DTC number and FTB (Failure Byte Type) details. Developer should know below details.
Note: some DTCs should provide information to driver so DTC implementation should provide "Service Manual Notes"
Example :
======================================================================================================================================
Refence document:
======================================================================================================================================
Refence document:
AUTOSAR DCM Spec
AUTOSAR DEM Module
ARCCORE reference
Vector UDS Link
UDS Protocol Part1
UDS Protocol
DEM Configuration
======================================================================================================================================
Thanks for visiting the Post..!!
================================================================================================================================================================================================================
No comments:
Post a Comment