|
GM WORLDWIDE ENGINEERING STANDARDS
GMW3110
© Copyright 2010 General Motors All Rights Reserved
February 2010
Page 47 of 336
d. Wait for the VN to timeout (8 s + 1 s safety margin after the reception of the response from the previous
diagnostic request). Make sure that no subsequent bus wake-up occurs.
e. Transmit a physically addressed ReadDataByIdentifier ($1A) service with DataIdentifier $B0
(diagnosticAddress) to the node using the node
’s physical request CAN Identifier and make sure that the
node does not respond to this diagnostic request.
Note:
ECUs implementing a communications handler based on versions of GMW3104 prior to version 1.5 may
have an additional timer in the handler for deactivating local VNs. This timer value must be added to the 8 s
specified in this verification procedure above.
Acceptance Criteria:
The node shall not respond to the last transmitted ReadDataByIdentifier ($1A) service. This indicates that the
node has deactivated the initially active and application triggered diagnostic VN properly.
5.2.9 Example: Activation and Deactivation of the Application Triggered Diagnostic VN.
Note:
It is assumed that the Application Triggered Diagnostic VN is the only Active VN.
Figure 15 provides an additional example for the activation and deactivation of the application triggered
diagnostic VN. In the examples, it is assumed that the ECU is in the ECU_IN_STANDBY communication state
at the time the tester sends a wake-up. Following the wake-up, the diagnostic application enters the
DIAG_INACTIVE state.
1. The first request (1) is a multiple frame request message. Upon receipt of the FirstFrame, the Network
Layer provides an indication to the diagnostic application that a request has started. The diagnostic
application resets and disables the Appl_Diag_VN timer, tells the handler to activate the application
triggered diagnostic VN, and transitions into the DIAG_ACTIVE_TIMER_OFF state. At the end of the
SingleFrame response message the diagnostic application enables the Appl_Diag_VN_Timer and
transitions to the DIAG_ACTIVE_TIMER_ON state (since the requested service does not require
Diagnostic Mode and no response or request message is in progress).
2. The second request (2) is a SingleFrame request message that is received while the application triggered
diagnostic VN is already active. The Network Layer indicates to the diagnostic application that the
SingleFrame request has been received and the application resets and disables the Appl_Diag_VN_Timer
(transitions back to DIAG_ACTIVE_TIMER_OFF state). The requested service requires the node to enable
Diagnostic Mode and therefore the application layer transitions into the DIAG_MODE_ACTIVE state and
does not enable Appl_Diag_VN_Timer after the transmission of the response message.
3. The third request (3) is a functionally addressed SingleFrame TesterPresent message which results in the
node resetting the TesterPresent timer (P3
C
) to keep Diagnostic Mode active. The diagnostic application
stays in the DIAG_MODE_ACTIVE state.
4. The fourth request (4) is a SingleFrame message for the ReturnToNormalMode ($20) service. Upon
receipt of the request, the Network Layer provides an indication to the diagnostic application that a
diagnostic service has started. The application then processes the $20 request which cancels Diagnostic
Mode and thus causes the ECU to transition into the DIAG_ACTIVE_TIMER_OFF state. Upon receiving
confirmation from the network layer that the response was successfully transmitted, the diagnostic
application transitions to the DIAG_ACTIVE_TIMER_ON state. After 8 s elapses, the application informs
the handler to deactivate the application triggered diagnostic VN and transitions into the DIAG_INACTIVE
state. Since the initially active diagnostic VN is already deactivated at this point, the diagnostic application
then transitions into the DIAG_DISABLED state.
--``,,``````,``,,``,,,`,`,`,,-`-`,,`,,`,`,,`---
CameraLoops.com
Do'stlaringiz bilan baham: |
