Document Name:

CAN Communication Strategy Specification

Approved By: File Reg no Info Class

GB5200_CAN_Communication_Strategy_Specification.do
CAN Strategy Development Team
cx
GB5200 II

Issued by: Date Issue Page

Katrina Schultz 11/30/2017 20.20.137 1 (75)

General Motors Company

CAN Communication Strategy Specification

Release: 20.20.137

Release Date: 11/30/2017

GM Confidential ©2017 General Motors LLC. All Rights Reserved

 Document Name:

CAN Communication Strategy Specification

Approved By: File Reg no Info Class

GB5200_CAN_Communication_Strategy_Specification.do
CAN Strategy Development Team
cx
GB5200 II

Issued by: Date Issue Page

Katrina Schultz 11/30/2017 20.20.137 2 (75)

Table Of Contents
1 Introduction .......................................................................................................................................... 5
1.1 Document Updates and Revision History ..................................................................................... 5
1.1.1 Issue History .......................................................................................................................... 5
1.1.2 Revision Log .......................................................................................................................... 5
1.2 Document Scope ......................................................................................................................... 13
1.3 Document Mission/Theme ......................................................................................................... 13
1.4 Document Status Classification................................................................................................... 13
1.5 Requirement Wording Conventions ........................................................................................... 13
2 References .......................................................................................................................................... 14
2.1 Precedence Order ....................................................................................................................... 14
2.2 Government Documents............................................................................................................. 14
2.3 General Motors Documents ....................................................................................................... 14
2.4 Industry Documents .................................................................................................................... 15
2.4.1 AUTOSAR ............................................................................................................................. 15
2.4.2 ISO ....................................................................................................................................... 16
2.4.3 SAE ...................................................................................................................................... 16
2.4.4 Protocol Specific Documents .............................................................................................. 16
2.4.4.1 CAN.................................................................................................................................. 16
2.5 Definitions and Acronyms ........................................................................................................... 16
3 Requirements ...................................................................................................................................... 20
3.1 General........................................................................................................................................ 20
3.2 ISO Seven Layer Model Requirements ........................................................................................ 20
3.2.1 Physical Layer Requirements .............................................................................................. 20
3.2.1.1 Network Topology ........................................................................................................... 21
3.2.1.2 Supported Network Data Rates ...................................................................................... 23
3.2.2 Data Link Layer Requirements ............................................................................................ 23

GM Confidential ©2017 General Motors LLC. All Rights Reserved

 Document Name:

CAN Communication Strategy Specification

Approved By: File Reg no Info Class

GB5200_CAN_Communication_Strategy_Specification.do
CAN Strategy Development Team
cx
GB5200 II

Issued by: Date Issue Page

Katrina Schultz 11/30/2017 20.20.137 3 (75)

3.2.2.1 Identifier Structure.......................................................................................................... 24

3.2.2.2 Identifier Range Reservations ......................................................................................... 24
3.2.3 Network Layer Requirements ............................................................................................. 24
3.2.3.1 Signal and PDU Definition ............................................................................................... 25
3.2.3.2 Message/Frame Definition ............................................................................................. 25
3.2.4 Transport Layer Requirements ........................................................................................... 27
3.2.4.1 Supported Transport Protocol Standards ....................................................................... 27
3.2.4.2 Transport Protocol Configuration ................................................................................... 27
3.2.5 Session Layer Requirements ............................................................................................... 27
3.2.6 Presentation Layer Requirements ...................................................................................... 28
3.2.7 Application Layer Requirements ......................................................................................... 28
3.3 Communication Strategy Elements ............................................................................................ 28
3.3.1 Communication Activation ................................................................................................. 29
3.3.1.1 ECU_UNPOWERED State ................................................................................................. 30
3.3.1.2 ECU_POWERED State ...................................................................................................... 30
3.3.2 Network Management ........................................................................................................ 40
3.3.2.1 NETWORK_MANAGEMENT_ACTIVE ............................................................................... 41
3.3.2.2 Active Communication .................................................................................................... 48
3.3.2.3 Activation Process ........................................................................................................... 53
3.3.3 Transmit / Receive Models ................................................................................................. 57
3.3.3.1 Message Transmission .................................................................................................... 59
3.3.3.2 Message Reception ......................................................................................................... 67
3.3.4 Communication Deactivation ............................................................................................. 71
3.3.4.1 Shutdown Initiation Event .............................................................................................. 71
3.3.4.2 Shutdown Network Management Process ..................................................................... 71
3.3.4.3 Communication Deactivated State Entry ........................................................................ 74
3.3.5 Error Management.............................................................................................................. 74

GM Confidential ©2017 General Motors LLC. All Rights Reserved

 Document Name:

CAN Communication Strategy Specification

Approved By: File Reg no Info Class

GB5200_CAN_Communication_Strategy_Specification.do
CAN Strategy Development Team
cx
GB5200 II

Issued by: Date Issue Page

Katrina Schultz 11/30/2017 20.20.137 4 (75)

3.3.5.1 Bus Fault Mitigation and Recovery ................................................................................. 74

3.3.5.2 ECU Reset Recovery ........................................................................................................ 74
3.3.5.3 Diagnostic Support .......................................................................................................... 75
4 Appendix A .......................................................................................................................................... 75

GM Confidential ©2017 General Motors LLC. All Rights Reserved

 Document Name:

CAN Communication Strategy Specification

Approved By: File Reg no Info Class

GB5200_CAN_Communication_Strategy_Specification.do
CAN Strategy Development Team
cx
GB5200 II

Issued by: Date Issue Page

Katrina Schultz 11/30/2017 20.20.137 5 (75)

1 Introduction
1.1 Document Updates and Revision History
This document can be revised and appear in several versions. The document will be classified in order to
allow identification of updates and versions.

1.1.1 Issue History

Each issue is given a number and date. A history shall be kept over all issues.

1.1.2 Revision Log

Revision Date Chapter Description

Release 1.0 Sept 7, First issue

2012

Release 1.1, Sept 12, 3.2.1.1.3 Corrected network reference. Was: public, should
DRAFT 2012 be: Expansion

3.3.1.2.2.3.3 Update STD with correct version

3.3.2 Update STD with correct version

3.3.3.1 Added additional transmit details to sub chapters

3.3.3.2 Added additional receive details to sub chapters

Sept 13, 3.3.1.2.2.2, Added logic to keep network active for a minimum
2012 amount of time following a sleep to wake transition
3.3.1.2.2.3.1,
& local activation.
3.3.1.2.2.3.3.2.3

Sept 20, 3.3, 3.3.1.2.2.3.3.2.2, Added network management logic to support

2012 diagnostic testers.
3.3.1.2.2.3.3.2.3,
3.3.2.2.2

3.3.3.1.3. Declared BID ENDIAN encoding for transmitted

signals.

Oct 12, Updated Figures 1, 2, 3, 4, 6, 7, 8, 9, 10, 12, 13, 20

2012

GM Confidential ©2017 General Motors LLC. All Rights Reserved

 Document Name:

CAN Communication Strategy Specification

Approved By: File Reg no Info Class

GB5200_CAN_Communication_Strategy_Specification.do
CAN Strategy Development Team
cx
GB5200 II

Issued by: Date Issue Page

Katrina Schultz 11/30/2017 20.20.137 6 (75)

Revision Date Chapter Description

3.3.1.2.2.1, 3.3.1.2.2.2, Added communication synchronization timers so

3.3.2.1.3.1 activating and activated ECUs wait a synchronization
period of time before enabling signals for
transmission and reception.

3.3.2.1.2, Implemented a more robust wakeup pattern to

satisfy partial network transceiver wake logic and
3.3.2.3,
slow waking ECUs
3.3.2.3.1

Release 1.1 Oct 12, Second issue

2012

Release 1.2, Oct 23, 1.5 Removed [REQ] references, added attributes
DRAFT 2012 Heading, Information, and Functional.

2.3, Added reference to GM UDS requirements [UDS].

3.2.3.3, Added requirement that diag msg defined in DD.

3.2.3.3.2, 3.2.3.3.3, Removed sections defining Diagnostic messages

3.2.3.3.4, 3.2.3.3.5
In 3.2.3.3.2 added reference re. diag msg def found
in [UDS]

Release 1.2 Dec 14, Third issue

2012

Release 1.3, March 16, all sections Change all references of GMW3122 to GB7200,
DRAFT 2013 Change all references of I-doc to GB6001, Changed
all references of UDS spec to GB6000

3.2.2.1 Added requirements GBCCS387 (bootloader will use

11 bit headers)

3.2.2.2 Updated reserved identifier ranges

Added $600 - $6FF as reserved

GM Confidential ©2017 General Motors LLC. All Rights Reserved

 Document Name:

CAN Communication Strategy Specification

Approved By: File Reg no Info Class

GB5200_CAN_Communication_Strategy_Specification.do
CAN Strategy Development Team
cx
GB5200 II

Issued by: Date Issue Page

Katrina Schultz 11/30/2017 20.20.137 7 (75)

Revision Date Chapter Description

Deleted $18CD0000 - $18CDFFFF as reserved

Deleted $18DE0000 - $18CEFFFF as reserved

Added $10DB0000 - $10DBFFFF as reserved

Added $14DA0000 - $14DAFFFF as reserved

Added $14DC0000 - $14DCFFFF as reserved

Changed the Requirement Type attribute for the

cells containing the reserved range values from
Information to Functional

3.2.3.3 requirement GBCCS1027, Changed the Requirement

Type attribute from Information to Functional

Release 1.3 March 16, Fourth Issue

2013

all sections Added attributes to indicate which objects apply to

the Private, Public, or Expansion networks to
faciltate export of separate documents (GB5200 for
Public and Expansion networks and GB5210 for
Private networks) containing only those
requirements that apply to the specific network
types

all sections removed "[]" from document references

2.3 Added GMW3122

2.5 Added CAN-FD to list of acronyms

3.2, 3.2.1.1 Changed "ECU's" to "ECUs" in GBCCS304 and

GBCCS312

3.2.1.2 Added CAN-FD rates for 500 and 125 k networks per
CR 14811

GM Confidential ©2017 General Motors LLC. All Rights Reserved

 Document Name:

CAN Communication Strategy Specification

Approved By: File Reg no Info Class

GB5200_CAN_Communication_Strategy_Specification.do
CAN Strategy Development Team
cx
GB5200 II

Issued by: Date Issue Page

Katrina Schultz 11/30/2017 20.20.137 8 (75)

Revision Date Chapter Description

3.2.1.3.1 Removed GBCCS360 - this information is in the

hardware specifications

3.2.1.1.6, 3.2.1.2, Added information statements and requirements for

3.2.1.3, 3.2.1.3.1, Private networks - GBCCS1210, GBCCS1211,
3.2.1.3.2, 3.2.1.3.4, GBCCS1212, GBCCS1228 - GBCCS1235, GBCCS1238,
3.2.1.4, 3.2.2, 3.2.4, GBCCS1240 - GBCCS1244, GBCCS1247, GBCCS1248,
3.3.1, 3.3.1.2.2, GBCCS1251, GBCCS1252, GBCCS1259 - GBCCS1265,
3.3.1.2.2.2, GBCCS1270, GBCCS1271, GBCCS1273 - GBCCS1290
3.3.1.2.2.3.1,
3.3.2.2.3.1, 3.3.2.2.3.3,
3.3.2.3, 3.3.2.3.1,
3.3.2.3.2, 3.3.3.1.1,
3.3.3.1.2, 3.3.3.1.4,
3.3.3.1.4.1, 3.3.3.1.5,
3.3.3.2.1, 3.3.3.2.2,
3.3.3.2.5, 3.3.3.2.6,
3.3.4.1

3.2.5 Split information statement GBCCS506 into

GBCCS504 and GBCCS1236

3.3.1.2.2.3 Split information statement GBCCS573 into

GBCCS573 and GBCCS1245, added information
statement GBCCS1246 for Private networks

3.3.2 Split information statement GBCCSS624 into

GBCC624 and GBCCS1253

3.3.2.2 deleted word “and” from information statement

GBCCS696, Changed information statement
GBCCS697 from
“NORMAL_COMM_HALT_MONITOR_ACTIVE
responsible for managing the tester service request
to halt normal communications.” to
“DIAGNOSTIC_COMMAND_MONITOR_ACTIVE,
responsible for managing the tester service

GM Confidential ©2017 General Motors LLC. All Rights Reserved

 Document Name:

CAN Communication Strategy Specification

Approved By: File Reg no Info Class

GB5200_CAN_Communication_Strategy_Specification.do
CAN Strategy Development Team
cx
GB5200 II

Issued by: Date Issue Page

Katrina Schultz 11/30/2017 20.20.137 9 (75)

Revision Date Chapter Description

requests”, Changed COMMUNICATION+ACTIVE to

COMMUNICATION_ACTIVE in information
statement GBCCS698, Added information
statements GBCCS1254, GBCCS1255, GBCCS1257,
and GBCCS1258 for Private networks

3.3.3.2.4 Updated Figure 18 for Public and Expansion buses,

added separate diagram for Privated buses - per
CR104416

3.3.4.2 Added requirements GBCCS1291 and GBCCS1292

for Private networks, Changed word “following” to
“follows” in information statement GBCCS969,
Added information statement GBCCS1293 for
Private Networks

3.3.5.1 Changed last sentence in first paragraph from “The

faulty ECU will continue to receive messages while it
recovers from a bus off.” to “The faulty ECU will not
receive messages while it recovers from a bus off.”

3.3.5.2 Added information statement GBCCS1294 for

Private networks

Release 1.4 Sept. 16, Released documents GB5200 and GB5210

2013

Nov. 8, 3.2.1.1.1 Added new heading section 3.2.1.1.1, moved

2013 existing section 3.2.1.1.1 to 3.2.1.1.1.1, moved
existing section 3.2.1.1.2 to 3.2.1.1.1.2, moved
existing section 3.2.1.1.3 to 3.2.1.1.1.3

3.2.1.1.1.4 Added section for Point-to-Point networks

3.2.1.1.2 Added new heading section 3.2.1.1.2, moved

existing section 3.2.1.1.4 to 3.2.1.1.2.1, moved

GM Confidential ©2017 General Motors LLC. All Rights Reserved

 Document Name:

CAN Communication Strategy Specification

Approved By: File Reg no Info Class

GB5200_CAN_Communication_Strategy_Specification.do
CAN Strategy Development Team
cx
GB5200 II

Issued by: Date Issue Page

Katrina Schultz 11/30/2017 20.20.137 10 (75)

Revision Date Chapter Description

existing section 3.2.1.1.5 to 3.2.1.1.2.2, moved

existing section 3.2.1.1.6 to 3.2.1.1.2.3

Release 1.5 Feb. 2, 2014 Release documents GB5200 and GB5210

3.3.3.2.6.1 Added objects GBCCS1508 - GBCCS1514

3.3.4.2 Added object GBCCS1491

3.3.4.2 Added object GBCCS1474

3.3.2.2.3 Added objects GBCCS1492 - GBCCS1498

3.3.2.2.3.1 Added objects GBCCS1499

3.2.2.2 Added objects GBCCS1461 - GBCCS1463

Release 1.6 May 19, Release documents GB5200 and GB5210

2014

3.2.3.2 Modified object GBCCS473, Added objects

GBCCS1546-GBCCS1548

3.2.3.3 added objects GBCCS1544 and GBCCS1545

3.3.1.2.2.3 Added reference to NETWORK MODE MIN TIMER to

GBCCS585

3.3.2.3 Added NETWORK MODE MIN TIMER and removed

implementation specific details from GBCCS752

Release 1.7 October 26, Release documents GB5200 and GB5210

2014

December 3.2.3.3 Added objects GBCCS1586 and GBCCS1587

9, 2014

December 3.2.3.2 changed word "messages" to "frames" in objects

11, 2014 GBCCS437, GBCCS1546, GBCCS1547, and
GBCCS1548

GM Confidential ©2017 General Motors LLC. All Rights Reserved

 Document Name:

CAN Communication Strategy Specification

Approved By: File Reg no Info Class

GB5200_CAN_Communication_Strategy_Specification.do
CAN Strategy Development Team
cx
GB5200 II

Issued by: Date Issue Page

Katrina Schultz 11/30/2017 20.20.137 11 (75)

Revision Date Chapter Description

Release 1.8 December Release of version 1.8 of GB5200 and GB5210

12, 2014

January 5, 3.2.3.1 Added objects GBCCS1601 and GBCCS1602

2015

March 13, 3.2.3.3.1 Added object GBDDS1678

2015

March 13, 2.5 Added defintiions of Classic CAN message and CAN
2015 FD message

May 4, 2.4.4.1 Added reference to Bosch CAN 2.0 specification

2015

March 3, 3.3.3.1.4.1.1 added section

2015

March 3, 3.3.3.1.4.2.1 added section

2015

March 3, 3.3.3.1.4.3.1 added section

2015

March 3, 3.3.3.1.4.4.1 added section

2015

Release 1.9 June 8, 3.2.1.1, 3.2.1.1.1 Removed Expansion Network profile

2015

Release 1.9 July 6, 2016 3.3.3.2.2 removed objects GBCCS922, GBCCS923, GBCCS924

Added object GBCCS1286 to GB5200

Release 2.0 July 14, 3.3.3.2.4, 3.3.3.2.6.1 remove figures 18 and 19. added objects
2015 GBCCS1711 - GBCCS1717

Release 2.0 July, 27, all fixed spelling and grammar errors, removed sections
2015 from GB5210 that do not apply to Private networks,
added all transmit models to GB5210, removed

GM Confidential ©2017 General Motors LLC. All Rights Reserved

 Document Name:

CAN Communication Strategy Specification

Approved By: File Reg no Info Class

GB5200_CAN_Communication_Strategy_Specification.do
CAN Strategy Development Team
cx
GB5200 II

Issued by: Date Issue Page

Katrina Schultz 11/30/2017 20.20.137 12 (75)

Revision Date Chapter Description

duplicate requirements, removed statements that

were identified as requirements that were not
actual requirements

Release 2.1 March 2, 3.2.2 added requirement to interleave CAN 2.0 and CAN
2016 FD messages

Release 2.1 March 2, 3.3.3.1.3 correct endianness requirement GBCCS797

2016

Release 2.1 April 21, 3.2.2.2 added additional reserved range of 29 bit identifiers
2016

Release 2.2 October 14, 3.3.2.3.2 added requirement to enable receive PDUs each
2016 time NMF is received

Release 2.2 June 3, 3.2.3.2 added requirements that CAN IDs for diagnsotic,
2016 Protected signals, and counter sync signals be
unique across Public networks, clarified that NMF
CAN IDs be unique across Public networks

Release 2.2 August 9, many Removed VD and VDA. Replaced as appropriate

2016 with Loss of Comm Fault Active

Release 2.3 November 3.3.2.3.2 added requirement to enable receive PDU groups
25, 2016 each time a NMF is received

20.20.137 September 2.5, 3.2.3.2.1 Changed Classic CAN to Classical CAN to match ISO
18, 2017 11898

20.20.137 September 3.2.1.1.2.1 clarified requirement that ECU has to receive and
18, 2017 process all messages, except when bus off

20.20.137 September 3.3.3.1.5 added requirement that gateway shall be an Active

19, 2017 PNC gateway

GM Confidential ©2017 General Motors LLC. All Rights Reserved

 Document Name:

CAN Communication Strategy Specification

Approved By: File Reg no Info Class

GB5200_CAN_Communication_Strategy_Specification.do
CAN Strategy Development Team
cx
GB5200 II

Issued by: Date Issue Page

Katrina Schultz 11/30/2017 20.20.137 13 (75)

Revision Date Chapter Description

20.20.137 September 3.3.2.3.1 added requirement to hold PN bit until Repeat

19, 2017 Message Time expires, clarified wakeup pattern
requirements

20.20.137 September 3.3.3.1.4.1, 3.3.3.2.5 added requirement on periodic rates when software
19, 2017 can't meet specified value

1.2 Document Scope

This specification establishes the communication strategy for the GM In-Vehicle Controller Area
Network (CAN) Subsystems. Implementation of this strategy is required for all Electronic Control Units
(ECU’s) connected to the network.

1.3 Document Mission/Theme

The In-Vehicle CAN Network subsystem shall provide a reliable, cost effective, flexible and modular way
to handle information sharing between ECU’s in the vehicle through the means of a family of serial
communication networks.

The In-Vehicle CAN Network subsystem shall be scaleable to support ECU’s that range from simple
control modules up to highly complex units.

The In-Vehicle CAN Network subsystem shall also support the transfer of diagnostic services and the
transformation from and to a specified set of globally accepted standards for diagnostic tester access
and communication.

1.4 Document Status Classification

The document is assigned the status Outline, Draft or Specification. It will have the Outline status during
the initial phase when parts of the document are not yet written. The Draft status is entered when a
complete document is ready, which can be submitted for reviews. The Draft is not approved. A
Specification is established when the document is reviewed, corrected and approved and released in an
issue version.

1.5 Requirement Wording Conventions

Within this document the following conventions are applied:

 Shall – a binding requirement of the component or subsystem within the scope of this
specification.
 Must – a requirement of a components or subsystem outside of the scope of this specification.

GM Confidential ©2017 General Motors LLC. All Rights Reserved

 Document Name:

CAN Communication Strategy Specification

Approved By: File Reg no Info Class

GB5200_CAN_Communication_Strategy_Specification.do
CAN Strategy Development Team
cx
GB5200 II

Issued by: Date Issue Page

Katrina Schultz 11/30/2017 20.20.137 14 (75)

 Will – a result of an immutable law of physics.

 Withstand – all functions of a component perform as specified during and after exposure to the
defined condition without inadvertent actuation of its outputs.
 Should – denotes a preference or desired conformance
 Rationale: - describes the rationale behind a requirement. Ultimately the rationale shall be
described in such a way that a reader of the document can understand the motivation for a
specific requirement, even if the reader was not part of the discussion or creation of the
requirement.

2 References
2.1 Precedence Order
In case of conflict between the text of this specification and the documents cited herein, the text of this
specification takes precedence. Nothing in this specification, however, supersedes applicable laws and
regulations unless a specific exemption has been obtained.

2.2 Government Documents

N/A

2.3 General Motors Documents

Document Document Title Document
Number Version

GB72XX Dual Wire CAN Physical Layer and Data Link Specification December 2012 or
greater

GMW3173 GMLAN Architecture and Bus Wiring Requirements V3.0 (July 2008)

GB6001 Diagnostic Infrastructure Specification December 2012 or

greater

GB6000 Unified Diagnostics Services Specification December 2012 or

greater

GB5280 Global B Partial Network Deployment Specification June 2015 or greater

GM Confidential ©2017 General Motors LLC. All Rights Reserved

 Document Name:

CAN Communication Strategy Specification

Approved By: File Reg no Info Class

GB5200_CAN_Communication_Strategy_Specification.do
CAN Strategy Development Team
cx
GB5200 II

Issued by: Date Issue Page

Katrina Schultz 11/30/2017 20.20.137 15 (75)

2.4 Industry Documents

2.4.1 AUTOSAR
Document Number Document Title Document
Version

AUTOSAR_SWS_BSWModeM Specification of Basic Software Mode Manager R4.0 Rev 3

anager
V1.2.0

AUTOSAR_SWS_CANDriver Specification of CAN Driver R4.0 Rev 3

V4.0.0

AUTOSAR_SWS_CANInterfac Specification of CAN Interface R4.0 Rev 3

e
V5.0.0

AUTOSAR_SWS_CANNetwork Specification of CAN Network Management R4.0 Rev 3

Management
V3.3.0

AUTOSAR_SWS_CANStateMa Specification of CAN State Manager R4.0 Rev 3

nager
V2.2.0

AUTOSAR_SWS_CANTranscei Specification of CAN Transceiver Driver R4.0 Rev 3

verDriver
V3.0.0

AUTOSAR_SWS_CANTranspo Specification of CAN Transport Layer R4.0 Rev 3

rtLayer
V4.0.0

AUTOSAR_SWS_COM Specification of Communication R4.0 Rev 3

V4.2.0

AUTOSAR_SWS_COMManag Specification of Communication Manager R4.0 Rev 3

er
V4.0.0

AUTOSAR_SWS_ECUStateMa Specification of ECU State Manager R4.0 Rev 3

nager
V3.0.0

GM Confidential ©2017 General Motors LLC. All Rights Reserved

 Document Name:

CAN Communication Strategy Specification

Approved By: File Reg no Info Class

GB5200_CAN_Communication_Strategy_Specification.do
CAN Strategy Development Team
cx
GB5200 II

Issued by: Date Issue Page

Katrina Schultz 11/30/2017 20.20.137 16 (75)

Document Number Document Title Document

Version

AUTOSAR_SWS_NetworkMa Specification of Network Management Interface R4.0 Rev 3

nagementInterface
V3.0.0

AUTOSAR_SWS_PDURouter Specification of PDU Router R4.0 Rev 3

V3.2.0

2.4.2 ISO
Document Document Document Title Document
Number Reference Version

ISO 11898-1 ISO11898-1 Road vehicles - Interchange of digital information - ISO/DIS 11898-
Controller area network (CAN) for high-speed 1 (Ed 2)
communication

ISO 11898-6 ISO11898-6 Road vehicles - Interchange of digital information -

Controller area network (CAN) for high-speed
communication

ISO-WD 15765- ISO15765 Road Vehicles - Diagnostic Systems -

2 Network/Transport USDT Protocol
(Unacknowledged Segmented Data Transfer)

2.4.3 SAE
N/A

2.4.4 Protocol Specific Documents

2.4.4.1 CAN
Bosch CAN Specification, Version 2.0

2.5 Definitions and Acronyms

Term Definition

Activated ECU A member of an active partial network.

Activating ECU ECU assigned to monitor and process partial network activation criteria.

GM Confidential ©2017 General Motors LLC. All Rights Reserved

 Document Name:

CAN Communication Strategy Specification

Approved By: File Reg no Info Class

GB5200_CAN_Communication_Strategy_Specification.do
CAN Strategy Development Team
cx
GB5200 II

Issued by: Date Issue Page

Katrina Schultz 11/30/2017 20.20.137 17 (75)

Term Definition

Activation - active Process in which activating ECUs monitor local events and cause partial
networks to become actively communicating. Partial networks are considered
locally activated.

Activation - passive Process in which network members are notified from a remote ECU via the
network that a partial network is activating. Partial networks are considered
remotely activated.

Activation criteria Conditional requirements used to determine when a partial network should be
activated.

Bus Off An error state defined in ISO 11898, a controller in bus off is switched off from
the bus

CAN FD message CAN message transmitted using the ISO defined CAN FD frame format. CAN FD
= CAN Flexible Data. CAN FD messages can be transmitted with a faster baud
rate for the payload portion of the message or with up to 64 bytes of data or
both.

Classical CAN message CAN message that is transmitted with the frame format defined in the Bosch
CAN 2.0 specification.

Data field consists of the data to be transferred within a frame. It can contain from 0 bytes
to 64 bytes, and each byte contains 8 bits.

Data Dictionary Representation of signals, PDU, and messages and the assignments of these to
the transmitting and receiving ECUs.

Deactivation criteria Conditional requirements used to determine when a partial network should be
allowed to expire.

Frame Data link protocol unit specifying the arrangement and meaning of bits or bit
fields in the sequence of transfer across the transmission medium.

Gateway A multi-network ECU responsible for transferring data from one network to
another.

The networks do not have to be the same protocol.

GM Confidential ©2017 General Motors LLC. All Rights Reserved

 Document Name:

CAN Communication Strategy Specification

Approved By: File Reg no Info Class

GB5200_CAN_Communication_Strategy_Specification.do
CAN Strategy Development Team
cx
GB5200 II

Issued by: Date Issue Page

Katrina Schultz 11/30/2017 20.20.137 18 (75)

Term Definition

Message A group or collection of signals

Multi-Network Member An ECU that communicates in more than one physical network.

Network Activation Process in which a network transitions from inactive to active communications.

Network Management Message who’s data payload is formatted to notify which partial networks are
Frame active or inactive.

Network Member An ECU that communicates in a network.

Partial Network Collections of signals whose transmission and reception are started and stopped
as a unit. Partial Networks may be started and stopped independently of each
other.

Partial Network Cluster Collections of ECUs who participate in a partial network.

Partial Network Cluster An ECU that participates in a partial network cluster.

Member

PDU Collection of signals that an ECU sends and receives in support of a specific
Partial Network

PDU group Collection of PDUs that an ECU sends and receives in support of a specific Partial
Network

Signal The implemented representation of data

Signal group A group of signals that must be read and written as a unit without interruption
to ensure data coherency.

Signal supervision Deadline monitoring for a signal from an ECU assigned to transmit it on a
regular interval. If the deadline is missed, the ECU is notified.

Acronyms Explanation

ASR AUTOSAR

AUTOSAR AUTomotive Open System ARchitecture

GM Confidential ©2017 General Motors LLC. All Rights Reserved

 Document Name:

CAN Communication Strategy Specification

Approved By: File Reg no Info Class

GB5200_CAN_Communication_Strategy_Specification.do
CAN Strategy Development Team
cx
GB5200 II

Issued by: Date Issue Page

Katrina Schultz 11/30/2017 20.20.137 19 (75)

Acronyms Explanation

CAN Controller Area Network

CAN-FD Controller Area Network with Flexible Data Rate

CC Communication Controller

CRC Cyclic Redundancy Check

CTS Component Technical Specification

DD Data Dictionary

DLL Data Link Layer

DTC Diagnostic Trouble Code

ECU Electronic Control Unit

EEPROM Electrically Erasable Programmable Read Only Memory

EMC Electromagnetic Compatibility

ENM Enumerated signal type

ESD Electrostatic Discharge

GMW General Motors Worldwide

HW Hardware

ID Identifier

ISO International Organization for Standardization

LSB Least Significant Bit/Byte

MSB Most Significant Bit/Byte

N/A Not Applicable

NM Network Management

NMF Network Management Frame

GM Confidential ©2017 General Motors LLC. All Rights Reserved

 Document Name:

CAN Communication Strategy Specification

Approved By: File Reg no Info Class

GB5200_CAN_Communication_Strategy_Specification.do
CAN Strategy Development Team
cx
GB5200 II

Issued by: Date Issue Page

Katrina Schultz 11/30/2017 20.20.137 20 (75)

Acronyms Explanation

PDU Protocol Data Unit

PN Partial Network

PNC Partial Network Cluster

SAE Society of Automotive Engineers

SSTS Sub-System Technical Specification

STD State Transition Diagram

TBD To Be Defined

3 Requirements
3.1 General
The CAN Communication Strategy specification captures WHAT the serial data communication network
shall do to robustly send and receive data under normal and abnormal operating conditions. The CAN
Software Strategy specification captures HOW the requirements of the Communication Strategy shall be
implemented.

3.2 ISO Seven Layer Model Requirements

In-vehicle CAN Network communication strategy relies on the interaction of hardware and software
within an ECU and between other ECUs connected to the network. Communication functionality has
been developed using a modular approach following the ISO/OSI seven layer reference model.

3.2.1 Physical Layer Requirements

The physical layer provides a method for converting the digital data symbols (1’s and 0’s) generated by
the data link layer into electrical signals transmitted on the communications medium. The Physical Layer
includes the following.

Transceiver: Electrical circuit that connects the CAN communication controller to the network.

Network Loading: Electrical load consists of the resistance and capacitance on the network line(s).

Filter: Circuitry which include (but not limited to) an inductor and capacitor necessary to improve
EMI immunity.

GM Confidential ©2017 General Motors LLC. All Rights Reserved

 Document Name:

CAN Communication Strategy Specification

Approved By: File Reg no Info Class

GB5200_CAN_Communication_Strategy_Specification.do
CAN Strategy Development Team
cx
GB5200 II

Issued by: Date Issue Page

Katrina Schultz 11/30/2017 20.20.137 21 (75)

Wiring: Physical media used to send/receive the electrical communication signals to/from network
members.

3.2.1.1 Network Topology

ECUs shall be able to communicate with one another using network(s) based on the CAN
communications protocol. [GBCCS312]

Vehicle Architectures shall be composed using one or more instantiations of CAN network(s).
[GBCCS313]

An ECU shall be either a network member, a multi-network member (MNM), or a gateway (GW).
[GBCCS315]
Expansion network

GW MNM
Private network

D
L
Public network C

3.2.1.1.1 Network Profiles

3.2.1.1.1.1 Public network
The public network shall be a general purpose network providing communications between multiple
subsystems / domains. [GBCCS318]

At least but not limited to one network member in the public network shall be assigned to manage and
control public network activation/deactivation. [GBCCS319]

The public network shall support partial networks. [GBCCS320]

The public network shall be accessible via the Data Link Connector or through a central gateway.
[GBCCS321]

3.2.1.1.1.2 Point-to-Point nework

The point-to-point network shall establish communications between two modules. [GBCCS1446]

GM Confidential ©2017 General Motors LLC. All Rights Reserved

 Document Name:

CAN Communication Strategy Specification

Approved By: File Reg no Info Class

GB5200_CAN_Communication_Strategy_Specification.do
CAN Strategy Development Team
cx
GB5200 II

Issued by: Date Issue Page

Katrina Schultz 11/30/2017 20.20.137 22 (75)

At least but not limited to one ECU in the point-to-point network shall be assigned to manage and
control point-to-point network activation/deactivation. [GBCCS1447]

Point-to-Point network bandwidth shall be available to the network members. [GBCCS1448]

The point-to-point network shall be tester accessible. [GBCCS1449]

The point-to-point network shall activate/deactivate as a uniform cluster (partial network support is not
required). [GBCCS1450]

3.2.1.1.2 Network membership

3.2.1.1.2.1 Network member
The ECU shall have the capability to receive and process all CAN messages it has been assigned
regardless of network bandwidth loading except when bus off. [GBCCS334]

The ECU shall have the capability to receive and process all CAN messages it has been assigned
regardless of when they are transmitted on the network except when bus off. [GBCCS1884]

The ECU shall have the capability to transmit all CAN messages it has been assigned when its transmit
model requirements have been met. [GBCCS335]

A network member shall support partial networks. [GBCCS336]

A network member shall be able to process remote network activation requests. [GBCCS337]

A network member shall be able to receive all Network Management Frames regardless of network
bandwidth loading. [GBCCS338]

A network member shall be configurable to be an activating ECU. [GBCCS339]

A network member shall transmit a Network Management Frame when it has been configured to be an
activating ECU and activation criteria are true. [GBCCS340]

3.2.1.1.2.2 Multi-network member (MNM)

A multi-network member shall be a network member on at least two networks. [GBCCS342]

3.2.1.1.2.3 Gateway (GW)

A gateway shall be a multi-network member. [GBCCS344]

A gateway shall transfer wake up requests from one network to all other networks. [GBCCS345]

A gateway shall transfer partial network management data from one network to all other networks.
[GBCCS346]

GM Confidential ©2017 General Motors LLC. All Rights Reserved

 Document Name:

CAN Communication Strategy Specification

Approved By: File Reg no Info Class

GB5200_CAN_Communication_Strategy_Specification.do
CAN Strategy Development Team
cx
GB5200 II

Issued by: Date Issue Page

Katrina Schultz 11/30/2017 20.20.137 23 (75)

A gateway shall be configured to transfer signal data from one network to other networks. [GBCCS347]

A gateway shall transfer wakeup requests, partial network management data and signal data within a
specified gateway transfer delay time that shall be a value ≤ 30ms.

Rationale: Gateway transfer delay time is influenced by the dependent function’s performance
characteristics, the number of signals it is transferring, and the networks it is connected to data rate(s).
Each gateway design shall specify the transfer delay time in accordance to these influences.
[GBCCS1736]

A gateway shall be configured to transfer block data from one network to other networks using the
network and transport layer. [GBCCS350]

A gateway shall be configured to synthesize ECU supervision data. [GBCCS351]

3.2.1.2 Supported Network Data Rates

Network data rates supported: 500Kbps, 125kbps.

CAN-FD data rate supported for 500Kbps: 2Mbps, 5Mbps [GBCCS1390]

CAN-FD data rate supported for 125Kbps: 500Kbps [GBCCS1391]

Each network shall have a specified data rate that provides network members enough serial data
capacity, bandwidth, throughout the network’s lifecycle. [GBCCS354]

Each network member shall have a configurable network data rate which shall be set in accordance with
the network it is connected.

Rationale: The ECU inherits the data rate of the network it is assigned. Whatever data rate is specified
for that particular network, the ECU will use that data rate to establish timing register values.
[GBCCS1737]

3.2.2 Data Link Layer Requirements

The data link layer (DLL) provides services for the transfer of individual frames between nodes. It
handles the protocol of the network system (bit timing, arbitration, error detection, etc.).

CAN DLL shall be CAN 2.0b active capable. [GBCCS379]

CAN DLL shall support mixed mode operation (i.e. handle 11 bit and 29 bit identifiers at run time).
[GBCCS380]

The CAN DLL shall support interleaving the transmission and reception of CAN 2.0 and CAN FD
messages. [GBCCS1797]

GM Confidential ©2017 General Motors LLC. All Rights Reserved

 Document Name:

CAN Communication Strategy Specification

Approved By: File Reg no Info Class

GB5200_CAN_Communication_Strategy_Specification.do
CAN Strategy Development Team
cx
GB5200 II

Issued by: Date Issue Page

Katrina Schultz 11/30/2017 20.20.137 24 (75)

3.2.2.1 Identifier Structure

Normal communication functional messages shall have 11bit Standard CAN identifiers. [GBCCS383]

Wakeup messages shall have 11bit Standard CAN identifiers. [GBCCS384]

Network management messages shall have 11bit Standard CAN identifiers. [GBCCS385]

Normal communication diagnostic messages shall have 29bit Extended CAN identifiers. [GBCCS386]

Bootloader diagnostic messages shall have both 11bit Standard CAN identifiers and 29bit Extended CAN
identifiers. [GBCCS387]

3.2.2.2 Identifier Range Reservations

The following 11bit Standard CAN identifiers shall be reserved: [GBCCS389]

11 bit IDs Description

$100 - $1FF Wakeup & Partial Network Management frames IDs

$600 - $6FF Diagnostic frame IDs

The following 29bit Extended CAN identifiers shall be reserved: [GBCCS407]

29 bit IDs Description

$10DB0000 – $10DBFFFF Diagnostic frame IDs

$10EBFEF0 – $10EBFEFF Diagnostic frame IDs

$14DA0000 – $14DAFFFF Diagnostic frame IDs

$14DC0000 – $14DCFFFF Diagnostic frame IDs

$18DA0000 – $18DAFFFF OBD/EOBD Diagnostic frame IDs

$18DB0000 – $18DBFFFF OBD/EOBD Diagnostic frame IDs

$18EF0000 – $18EFFFFF Diagnostic frame IDs

3.2.3 Network Layer Requirements

The network layer in conjunction with the transport layer transfers data using services of the data link
layer.

GM Confidential ©2017 General Motors LLC. All Rights Reserved

 Document Name:

CAN Communication Strategy Specification

Approved By: File Reg no Info Class

GB5200_CAN_Communication_Strategy_Specification.do
CAN Strategy Development Team
cx
GB5200 II

Issued by: Date Issue Page

Katrina Schultz 11/30/2017 20.20.137 25 (75)

3.2.3.1 Signal and PDU Definition

Signals and Signal Groups are defined in the Data Dictionary.

PDUs are defined in the Data Dictionary.

PDU Groups are defined in the Network Design.

States of an Enumerated signal not explicitly defined in the signal database shall be reserved for future
use. [GBCCS1601]

These states will not be defined as in the signal database as "Unused and Reserved", but may not be
used for other purposes.

3.2.3.2 Message/Frame Definition

CAN / CAN FD messages shall contain only one PDU. [GBCCS1544]

Communication in support of non-diagnostic functions shall be exclusively composed of functional

messages. [GBCCS1586]

An ECU acting as an onboard tester to collect data for a diagnostic or prognostic function shall be
allowed to use physically addressed diagnostic service messages to support this function. [GBCCS1587]

The CAN Identifier assigned to messages containing Protected signals shall be unique across all Public
CAN networks. [GBCCS1824]

The CAN Identifier assigned to messages containing Counter Sync signals shall be unique across all Public
CAN networks. [GBCCS1825]

3.2.3.2.1 Network Management Frame (NMF)

Network Management Frames (NMFs) are the messages used communicate between network members
the activated state of a partial network.

The NMF shall be transmitted as a Classical CAN message. [GBCCS1678]

NMFs shall be formatted in accordance with AUTOSAR_SWS_CANNetworkManagement: [GBCCS442]

CAN Frame Identifier CAN Data Field

Constant ECU Identifier Source Node Control Bit Partial Network Identifier Bits
001 b7-b0 Identifier Vector
Byte2 – Byte 7
b10-b8
Byte 0 Byte 1

GM Confidential ©2017 General Motors LLC. All Rights Reserved

 Document Name:

CAN Communication Strategy Specification

Approved By: File Reg no Info Class

GB5200_CAN_Communication_Strategy_Specification.do
CAN Strategy Development Team
cx
GB5200 II

Issued by: Date Issue Page

Katrina Schultz 11/30/2017 20.20.137 26 (75)

3.2.3.2.1.1 NMF CAN Frame Identifier

NMF CAN Frame Identifier shall contain the following two fields: Constant, ECU Identifier. [GBCCS454]

The Constant field shall reside in the high-order three bits of the CAN frame identifier. [GBCCS455]

The Constant field of the CAN Identifier shall be set to 001b. [GBCCS456]

The ECU Identifier field shall reside in the low-order eight bits of the CAN frame identifier. [GBCCS457]

The ECU Identifier field shall contain the unique Source Node Identifier which indicates which device is
transmitting the frame. [GBCCS458]

The Network Management Frame CAN Identifier assigned to each ECU shall be unique across all Public
CAN networks. [GBCCS459]

3.2.3.2.1.2 NMF CAN Data Field

3.2.3.2.1.2.1 NMF CAN Data Field – Source Node Identifier
Byte zero of the NMF CAN data field shall contain the Source Node Identifier. [GBCCS462]

3.2.3.2.1.2.2 NMF CAN Data Field – Control Bit Vector

Byte one of the NMF CAN data field shall contain the Control Bit Vector. [GBCCS464]

The Control Bit Vector shall be initialized with 0x00 during initialization. [GBCCS465]

The Control Bit Vector is defined in GB5280.

All ECUs that transmit NM Frames shall set the Repeat Mesage Request Bit in the Control Bit Vector to
zero (0) for all NM PDU transmissions. [GBCCS1738]

All ECUS that transmit NM Frames shall set the NM Coordinator Sleep Bit in the Control Bit Vector to
zero (0) for all NM PDU transmissions. [GBCCS1739]

All ECUs that transmit NM Frames shall set the Partial Network Information Bit in the Control Bit Vector
to one (1) for all NM PDU transmissions. [GBCCS1740]

The management of the Active Wakeup Bit in the Control Bit Vector is handled by the AUTOSAR CAN
NM module.

3.2.3.2.1.2.3 NMF CAN Data Field – Partial Network Identifier Bits

Bytes two through seven of the NMF CAN data field shall contain the Partial Network Identifier Bits.
[GBCCS482]

GM Confidential ©2017 General Motors LLC. All Rights Reserved

 Document Name:

CAN Communication Strategy Specification

Approved By: File Reg no Info Class

GB5200_CAN_Communication_Strategy_Specification.do
CAN Strategy Development Team
cx
GB5200 II

Issued by: Date Issue Page

Katrina Schultz 11/30/2017 20.20.137 27 (75)

The mapping of Partial Network Identifier Bits to specific Partial Networks shall be defined in GB5280.
[GBCCS1742]

The Activating ECU shall transmit a value of one in the Partial Network Identifier Bit corresponding to
the Partial Network that is being activated. [GBCCS484]

The Activating ECU shall transmit a value of zero in the Partial Network Identifier Bit corresponding to
the Partial Network that is not being activated. [GBCCS485]

3.2.3.2.2 Diagnostic Messages

Diagnostic messages shall be defined and formatted as stated within GB6000. [GBCCS1028]

The Diagnostic message CAN Identifiers assigned to each ECU shall be unique across all Public CAN
networks. [GBCCS1826]

3.2.4 Transport Layer Requirements

The transport layer in conjunction with the network layer transfers data packets up to 4095 bytes using
services of the data link layer. It provides an unacknowledged transport service (1:N communication,
1:1 communication). If long messages have to be transferred over the network, the transport layer
provides services for segmented data transfer. On the transmit side, the message is broken into
segments, each segment being short enough to fit in a CAN frame. On the receive side, individual
segments are assembled into a message.

The network layer also manages connection setup and flow control.

3.2.4.1 Supported Transport Protocol Standards

Transport Layer Functions shall be implemented in accordance with ISO-WD 15765-2: Road vehicles -
Diagnostic Systems - Network/Transport USDT Protocol. [GBCCS502]

3.2.4.2 Transport Protocol Configuration

Transport layer shall have a specified buffer size capable of supporting the ECU’s block transfer
requirements. [GBCCS504]

3.2.5 Session Layer Requirements

The session layer is used to control the start-up, shutdown and error handling for network members or a
subset of network members.

Bus visible network management data is used to indicate when a network member wants to activate a
particular communication session, partial network, and when the activating member no longer requires
the communication session active. Network members monitor the network management data to
determine when they are required to participate in the communication session.

GM Confidential ©2017 General Motors LLC. All Rights Reserved

 Document Name:

CAN Communication Strategy Specification

Approved By: File Reg no Info Class

GB5200_CAN_Communication_Strategy_Specification.do
CAN Strategy Development Team
cx
GB5200 II

Issued by: Date Issue Page

Katrina Schultz 11/30/2017 20.20.137 28 (75)

3.2.6 Presentation Layer Requirements

The presentation layer serves as the application program interface. It provides communication services
to the application abstracted from the network protocol. The presentation layer provides a signal level
interface to the data transmitted and receive via serial data. The presentation layer provides transmit
and receive notifications indicating network, node, and signal level status. The presentation layer is
configured with signals, signal groups, and frames to be communicated. The presentation layer
manages transmit models and processing data upon reception.

3.2.7 Application Layer Requirements

The application layer is where all the ECU executes its allocated functional requirements. Functional
requirements use data that has been received from the communication network members. Functional
requirements derive data values that can be communicated to the communication network members.
The application layer also assesses network activation criteria to determine when a communication
session is needed or no longer needed. It processes notifications from the communication stack to keep
track of communication network status and determines if alternative processing is required when errors
are detected.

3.3 Communication Strategy Elements

Communication strategy elements will define the requirements for starting and stopping a
communication session, transmitting and receiving data, and managing errors. Communication sessions
may be actively started based on local data within an ECU or passively started based on remote data
received by another ECU in the network. Network members may be asleep or already awake but not
actively communicating when activation criteria is detected or received. ECU management will
transition the ECU to a state where activation criteria will be assessed and communication sessions will
be managed.

Once an ECU determines that it will participate in a communication session, the ECU begins transmitting
data, processing received data, and monitoring the communication subsystem for errors.

Some communication sessions may only require a subset of the network members to participate. Partial
network management determines whether an ECU will participate and if so will manage enabling the
appropriate portions of data necessary to support the active partial network. [GBCCS1743]

While actively communicating the ECU can monitor its ability to transmit data without causing a
disturbance in the network, check received signals for valid states, and detect when other network
members are no longer present when they should be transmitting data it requires. The ECU will be
configured to react appropriately in the event an error is detected.

GM Confidential ©2017 General Motors LLC. All Rights Reserved

 Document Name:

CAN Communication Strategy Specification

Approved By: File Reg no Info Class

GB5200_CAN_Communication_Strategy_Specification.do
CAN Strategy Development Team
cx
GB5200 II

Issued by: Date Issue Page

Katrina Schultz 11/30/2017 20.20.137 29 (75)

While actively communicating the ECU may receive requests from a tester to stop its communication
session. The ECU will be configured to react appropriately in the event a halt communication request is
received.

While actively communicating the ECU continues to monitor local data and remote requests to detect
when a communication session is no longer needed. When the ECU has determined that a
communication session is no longer needed it begins the process of deactivating the communication
session. If it activated the communication session, it will transmit data notifying the other network
members that the session is no longer needed. Once all communication sessions within the ECU are
deactivated, the ECU can either remain in a state where local operations may be processed or return to
a low power sleep state.

Communication strategy elements execute within the ECU and are dependent on the services of the
infrastructure. Non-communication infrastructure elements are included to show their interaction with
the communication elements. Detailed requirements for the behavior of the infrastructure software
that are beyond communication element requirements are not covered in this document.

The desired behavior of the CAN communication strategy elements and its relationship to the rest of the
ECU logic are graphically represented in this document through the use of State Transition Diagrams
(STDs). Notational conventions for the state transition diagram are given in Appendix A.

Sections are titled to correspond to the states in the STDs. Individual requirements are documented
within the section (i.e., state) that is primarily responsible for implementing the requirement. If a
requirement is implemented by a combination of states, cross-references are made to the others.
Requirements that correspond to transitions between states are documented in the state from which
the transition originates.

Numerous requirements in this section rely on the concept of timers. For the purpose of these
requirements, timer operating states have been defined but actual timer maintenance processes are not
specified.

Timers shall begin their counting when the “Start” command is specified. [GBCCS521]

Timers shall stop their counting when the “Stop” command is specified. [GBCCS522]

Timers shall have reached their counting limit when the “Expired” conditional is specified. [GBCCS523]

3.3.1 Communication Activation

The following figure contains a high-level ECU STD that encompasses all of the sub-states of the ECU,
including ECU Management.

GM Confidential ©2017 General Motors LLC. All Rights Reserved

 Document Name:

CAN Communication Strategy Specification

Approved By: File Reg no Info Class

GB5200_CAN_Communication_Strategy_Specification.do
CAN Strategy Development Team
cx
GB5200 II

Issued by: Date Issue Page

Katrina Schultz 11/30/2017 20.20.137 30 (75)

ECU_UNPOWERED
[POWERED]
[not_POWERED]

ECU_POWERED
ECU_EXECUTING_RESET
RESET_COMPLETE
ECU_MANAGEMENT_ACTIVE
RESET

COMMUNICATION_MANAGEMENT_LOGIC

COMM_MANAGEMENT_INACTIVE

LOCAL_ACTIVATION_MONITOR_ACTIVE
REMOTE_WAKEUP_MONITOR_ACTIVE
COMM_INIT No Communication
LOCAL_EVENT
COMM_INIT_COMPLETE

WAKEUP_SOURCE

ECU_IN_STANDBY ECU_READY
STANDBY_OK

PASSIVE_NETWORK_REQUEST or
ACTIVE_NETWORK_REQUEST /
Start NETWORK_MODE_MIN_TIMER;
COMM = NO_COMM and
ALL_BUS_ASLEEP

COMM_MANAGEMENT_ACTIVE

Figure 1: Communication Activation

3.3.1.1 ECU_UNPOWERED State

This is the initial state of the ECU. In this state the ECU has no power applied.

The ECU shall detect when power is applied and begin executing its reset logic. [GBCCS529]

3.3.1.2 ECU_POWERED State

In this state the ECU is powered. This state decomposes hierarchically into two sub-states,
ECU_EXECUTING_RESET and ECU_MANAGEMENT_ACTIVE.

GM Confidential ©2017 General Motors LLC. All Rights Reserved

 Document Name:

CAN Communication Strategy Specification

Approved By: File Reg no Info Class

GB5200_CAN_Communication_Strategy_Specification.do
CAN Strategy Development Team
cx
GB5200 II

Issued by: Date Issue Page

Katrina Schultz 11/30/2017 20.20.137 31 (75)

The ECU shall detect when power is removed and return to the ECU_UNPOWERED state. [GBCCS532]

3.3.1.2.1 ECU_EXECUTING_RESET State

The ECU_EXECUTING_RESET state is a transient state. The ECU resides in this state while executing
reset logic then exits. Detailed requirements for behavior of the ECU’s reset logic are ECU-dependent
and are not covered in this communication requirements document.

Once the ECU reset logic has successfully completed the ECU shall initiate ECU Management activities.
[GBCCS535]

3.3.1.2.2 ECU_MANAGEMENT_ACTIVE State

Following execution of its reset logic, the ECU must transition to a state where it is able to detect
changes in its inputs. In this state the ECU’s infrastructure software is executing. Detailed requirements
for the behavior of the ECU Management software that are beyond the communication requirements
are not covered in this document.

When ECU Management is active three concurrent processes will address detecting remote wakeup
requests, assessing ECU specific communication activation criteria, and managing CAN communication
transitions from inactive-to-active and active-to-inactive:

REMOTE_WAKEUP_MONITOR_ACTIVE is responsible for detecting received remote wake up

requests,

LOCAL_ACTIVATION_MONITOR_ACTIVE is responsible for processing ECU application requests to

start communication sessions (partial networks), and

COMMUNICATION_MANAGEMENT_LOGIC which manages communication transitions from

inactive communication to actively communicating and actively communicating to inactive
communication when required.

The ECU shall detect when remote wakeup requests are received from the CAN network. [GBCCS542]

The ECU shall detect when ECU local applications require CAN communications. [GBCCS543]

Following power up or completing an ECU reset the ECU shall initialize communications. [GBCCS544]

ECUs shall manage communication transitions from inactive communication to actively communicating
and actively communicating to inactive communication. [GBCCS545]

The ECU shall detect if a reset occurs and begin executing its normal power up reset logic. [GBCCS546]

GM Confidential ©2017 General Motors LLC. All Rights Reserved

 Document Name:

CAN Communication Strategy Specification

Approved By: File Reg no Info Class

GB5200_CAN_Communication_Strategy_Specification.do
CAN Strategy Development Team
cx
GB5200 II

Issued by: Date Issue Page

Katrina Schultz 11/30/2017 20.20.137 32 (75)

3.3.1.2.2.1 REMOTE_WAKEUP_MONITOR_ACTIVE State

ECUs capable of activating a communication session (partial network) will notify the other network
members that a communication session is about to start by transmitting wakeup requests. ECUs will
have interface hardware capable of electrically moding the ECU when a pertinent wakeup request is
received. Since the ECU may process other wakeup sources, the ECU will determine if the electrical
moding was due to a received wakeup request or some other local event. Multi-network ECUs will have
the ability to receive wakeup requests on any of its CAN channels.

The following figure contains the REMOTE_WAKEUP_MONITOR_ACTIVE logic.

REMOTE_WAKEUP_MONITOR_ACTIVE
Expired REMOTE_NETWORK_WAKEUP_CONFIRMATION_TIMER /
Set LOCAL_EVENT;

AWAITING_REMOTE_NETWORK_WAKEUP_CHx

Detect WAKEUP_SOURCE / Confirmed REMOTE_NETWORK_WAKEUP /

Start REMOTE_NETWORK_WAKEUP_CONFIRMATION_TIMER; Stop REMOTE_NETWORK_WAKEUP_CONFIRMATION_TIMER;
Determine REMOTE_NETWORK_WAKEUP; Start PASSIVE_SYNCH_TIMER;
Set COMM == FULL_COMM_REQ;
Set PASSIVE_NETWORK_REQUEST;

Figure 2: Remote Wakeup Monitor

ECU interface hardware shall be configured to electrically wake the ECU upon detection of a specified
wakeup request or set of specified wakeup requests. [GBCCS551]

ECU shall be capable of discriminating a local event from a network wakeup request. [GBCCS552]

ECU shall notify that a passive network request was received once the network wakeup request is
validated (confirmed). [GBCCS553]

ECU shall request that communication be set to full communication once the network wakeup request is
validated (confirmed). [GBCCS554]

ECU shall start a communication synchronization timer once the network wakeup request is validated
(confirmed).

GM Confidential ©2017 General Motors LLC. All Rights Reserved

 Document Name:

CAN Communication Strategy Specification

Approved By: File Reg no Info Class

GB5200_CAN_Communication_Strategy_Specification.do
CAN Strategy Development Team
cx
GB5200 II

Issued by: Date Issue Page

Katrina Schultz 11/30/2017 20.20.137 33 (75)

Rationale: Activating ECUs and Activated ECUs wait a synchronization period of time allowing each to
become receive ready prior to enabling signals for transmission and reception. [GBCCS1745]

3.3.1.2.2.2 LOCAL_ACTIVATION_MONITOR_ACTIVE State

ECUs assigned to activate a communication session will also be assigned to monitor the communication
session’s activation and deactivation criteria. When the ECU detects that the activation criteria is true, it
will activate the communication session. The communication session will remain active for a minimum
amount of time following a local activation. Whenever the ECU activates the communication session, it
will generate a network wakeup request to ensure all communication session members are awake.
When the ECU detects that the deactivation criteria is true, it will deactivate its need for the
communication session.

CAN communication strategy supports more than one communication session, partial network. Each
partial network will have its own activation and deactivation criteria defined and logic to track the local
and remote activation requests

The following figure contains the LOCAL_ACTIVATION_MONITOR_ACTIVE logic.

LOCAL_ACTIVATION_MONITOR_ACTIVE

Detect LOCAL_EVENT /
Determine PN()_ACTIVATION_CRITERIA_STATUS;

AWAITING_LOCAL_ACTIVATION

Confirmed PN()_ACTIVATION_CRITERIA_STATUS and

PN()_LOCAL_REQ = DEACTIVE / Detect PN()_DEACTIVATION_CRITERIA_STATUS /
Set PN()_LOCAL_REQ == ACTIVE; Reset ACTIVE_NETWORK_REQUEST;
Set ACTIVE_NETWORK_REQUEST; Set PN()_LOCAL_REQ == DEACTIVE;
Set GENERATE_WAKEUP;
Start ACTIVE_SYNCH_TIMER;
Start NETWORK_MODE_MIN_TIMER;

Figure 3: Local Activation Monitor

GM Confidential ©2017 General Motors LLC. All Rights Reserved

 Document Name:

CAN Communication Strategy Specification

Approved By: File Reg no Info Class

GB5200_CAN_Communication_Strategy_Specification.do
CAN Strategy Development Team
cx
GB5200 II

Issued by: Date Issue Page

Katrina Schultz 11/30/2017 20.20.137 34 (75)

ECU shall be configured to activate one or more than one partial network. [GBCCS562]

Each partial network shall have activation and deactivation criteria defined. [GBCCS563]

ECU shall be configured to monitor and assess each configured partial network’s activation criteria and
deactivation criteria. [GBCCS564]

When the network’s activation criteria are assessed true and the ECU has not already activated the
network, the ECU shall activate the communication session. [GBCCS1242]

When the partial network’s activation criteria are assessed true and the ECU has not already activated
the partial network the ECU shall indicate its local request to activate the partial network. [GBCCS565]

When the partial network’s activation criteria are assessed true and the ECU has not already activated
the partial network the ECU shall request that a network wakeup be transmitted. [GBCCS566]

When the partial network’s activation criteria are assessed true and the ECU has not already activated
the partial network the ECU shall start a communication synchronization timer.

Rationale: Activating ECUs and Activated ECUs wait a synchronization period of time allowing each to
become receive ready prior to enabling signals for transmission and reception. [GBCCS1746]

When the partial network is being activated for the first time e.g. the partial network’s activation criteria
are assessed true and the ECU has not already activated the partial network, the ECU shall keep the
communication session active for a specified minimum amount of time. [GBCCS569]

When the partial network’s deactivation criteria are assessed true the ECU shall notify that an active
network request is no longer active. [GBCCS570]

When the partial network’s deactivation criteria are assessed true the ECU shall indicate that the local
request for the partial network is no longer active. [GBCCS571]

When the network’s deactivation criteria are assessed true the ECU shall notify that an active network
request is no longer active. [GBCCS1243]

When the network’s deactivation criteria are assessed true the ECU shall indicate that the local request
for the network is no longer active. [GBCCS1244]

3.3.1.2.2.3 COMMUNICATION_MANAGEMENT_LOGIC State

Communication management logic manages communication transitions from inactive communication to
actively communicating and actively communicating to inactive communication when required. Detailed

GM Confidential ©2017 General Motors LLC. All Rights Reserved

 Document Name:

CAN Communication Strategy Specification

Approved By: File Reg no Info Class

GB5200_CAN_Communication_Strategy_Specification.do
CAN Strategy Development Team
cx
GB5200 II

Issued by: Date Issue Page

Katrina Schultz 11/30/2017 20.20.137 35 (75)

requirements for the behavior of the Communication Management software that are beyond the
communication requirements are not covered in this document (COMM_MANAGEMENT_INACTIVE).

This logic contains three high-level states:

COMM_MANAGEMENT_INACTIVE summarizing at a high level processes that occur when the ECU
is not communicating,

COMM_INIT responsible for configuring the CAN controller and transceiver following power apply
and,

COMM_MANAGEMENT_ACTIVE responsible for managing communications sessions.

Communication management logic causes the ECU to begin the transition to active communication
when required following a remote wakeup request or processing a local communication session (partial
network) activation request. It also deactivates ECU communications when the communication services
are no longer required.

3.3.1.2.2.3.1 COMM_MANAGEMENT_INACTIVE State

When an ECU detects that communication services are no longer required it will deactivate
communication and transition to COMM_MANAGEMENT_INACTIVE. Detailed requirements for the
behavior within COMM_MANAGEMENT_INACTIVE are beyond the communication requirements and
are not covered in this document.

The COMM_MANAGEMENT_INACTIVE state contains two sub-states.

ECU_READY where the ECU may perform local operations which do not require communication,
and

ECU_IN_STANDBY where the ECU is not performing any operations and can enter a low-power
consumption state.

Detailed requirements for the transitions between these two sub-states are beyond the communication
requirements and are not covered in this document. Generically speaking, the ECU transitions from
ECU_IN_STANDBY to ECU_READY when it has local operations to perform that do not require
communication and transitions the opposite direction when these operations are no longer necessary.

The ECU shall begin the transition to active communication when either a remote wakeup request had
been detected or a local communication session (partial network) activation request had been
processed. [GBCCS584]

GM Confidential ©2017 General Motors LLC. All Rights Reserved

 Document Name:

CAN Communication Strategy Specification

Approved By: File Reg no Info Class

GB5200_CAN_Communication_Strategy_Specification.do
CAN Strategy Development Team
cx
GB5200 II

Issued by: Date Issue Page

Katrina Schultz 11/30/2017 20.20.137 36 (75)

The ECU shall keep the communication session active for a specified minimum amount of time
(NETWORK_MODE_MIN_TIMER) when either a remote wakeup request had been detected or a local
communication session (partial network) activation request had been processed. [GBCCS585]

The ECU shall determine if there are any conditions prohibiting communications. [GBCCS586]

The ECU shall allow communication as long as there are no conditions prohibiting communications.
[GBCCS587]

The ECU shall coordinate communication activation and deactivation across all of the ECU’s networks.
[GBCCS588]

3.3.1.2.2.3.2 COMM_INIT State

COMM_INIT is a transient state. In this state, the ECU initializes the CAN controller and transceiver
following power up or completing an ECU reset. The ECU transitions from COMM_INIT to
COMM_MANAGEMENT_INACTIVE as soon as the initialization logic is executed.

Following power up or completing an ECU reset the ECU shall initialize the CAN controller and
transceiver. [GBCCS591]

The ECU shall be in a NO_COMM state following communication initialization. [GBCCS592]

3.3.1.2.2.3.3 COMM_MANAGEMENT_ACTIVE State

In the COMM_MANAGEMENT_ACTIVE state and its sub-states, the ECU manages when it begins and
ends communication sessions in the network. It is entered when communication services are required
and exited when they are no longer needed.

The following figure contains additional detail of the COMM_MANAGEMENT_ACTIVE state.

COMM_MANAGEMENT_ACTIVE contains three concurrent processes, each with numerous sub-states.
One is related to Network Management, NETWORK_MANAGEMENT_ACTIVE, which will be specified in
that section of the specification. The other two are related to Communication Management:

COMM_MANAGEMENT_MONITOR responsible for transitions to and from active communications

and

NM_COORDINATOR_MONITOR_ACTIVE responsible for detecting when all the ECU’s CAN channels
are no longer needed (bus asleep).

NETWORK_MANAGEMENT_ACTIVE responsible for determining when particular communication

session will become active or inactive.

GM Confidential ©2017 General Motors LLC. All Rights Reserved

 Document Name:

CAN Communication Strategy Specification

Approved By: File Reg no Info Class

GB5200_CAN_Communication_Strategy_Specification.do
CAN Strategy Development Team
cx
GB5200 II

Issued by: Date Issue Page

Katrina Schultz 11/30/2017 20.20.137 37 (75)

COMM_MANAGEMENT_ACTIVE

COMM_MANAGEMENT_MONITOR
Detect no PASSIVE_NETWORK_REQUEST and
no ACTIVE_NETWORK_REQUEST /
Set COMM == NO_COMM;
Determine COMM_ALLOWED

COMM_ENABLED
ComM Request Pending State
NM_COORDINATION_MONITOR_ACTIVE

Expired WAIT_BUS_SLEEP_TIMER /
Set COMM == NO_COMM;
NETWORK_MANAGEMENT_ACTIVE

Detect COMM = FULL_COMM_REQ and

COMM_ALLOWED / Set BUS_SLEEP;
Set COMM == FULL_COMM;
Activate CAN channel(s);

COMM_PREPARE_TO_SLEEP
ComM Ready Sleep State

Detect COMM = FULL_COMM or

DCM_REQ = ACTIVE /
Activate CAN channel(s);
Detect All PN()_LOCAL_REQ = DEACTIVE and
All PN()_REMOTE_REQ = DEACTIVE and
All PN()_TIMEOUT_TIMER = expired and
DCM_REQ = DEACTIVE and
Expired NETWORK_MODE_MIN_TIMER and
Expired NM_TIMEOUT_TIMER /
Start WAIT_BUS_SLEEP_TIMER;

COMM_ACTIVE
ComM Full Communication State

Figure 4: Communication Session Management

The ECU shall transition to inactive communication when communication services are no longer
required and the network coordinator has confirmed that all CAN channels are no longer active (bus
asleep). [GBCCS600]
3.3.1.2.2.3.3.1 NM_COORDINATION_MONITOR_ACTIVE State
Network coordination is used to coordinate the shutdown of communication services for all of the ECUs
networks. If any network is active, communication services remain active. When all networks have
entered a sleep state, communication services can become inactive.

The following figure contains the NM_COORDINATION_MONITOR_ACTIVE logic.

GM Confidential ©2017 General Motors LLC. All Rights Reserved

 Document Name:

CAN Communication Strategy Specification

Approved By: File Reg no Info Class

GB5200_CAN_Communication_Strategy_Specification.do
CAN Strategy Development Team
cx
GB5200 II

Issued by: Date Issue Page

Katrina Schultz 11/30/2017 20.20.137 38 (75)

NM_COORDINATION_MONITOR_ACTIVE

ECU_COMMUNICATION_NETWORKS_INACTIVE

Detect any ECU network not BUS_SLEEP

Detect ECU networks BUS_SLEEP /

Deactivate CAN ch(s);
Set ALL_BUS_ASLEEP;

ECU_COMMUNICATION_NETWORK_ACTIVE

Figure 5: Network Coordination Monitor

Communication services shall remain active as long as one network is actively communicating.
[GBCCS605]

Communication services shall deactivate when no network is actively communicating. [GBCCS606]

Communication services shall notify ECU management when communication is no longer needed; all
networks are asleep. [GBCCS607]

3.3.1.2.2.3.3.2 COMM_MANAGEMENT_MONITOR State

COMM_MANGEMENT_MONITOR will manage transitioning the ECU from an enabled to communicate
state to an actively communicating state in conjunction with Network Management. When the ECU no
longer needs to actively communicate in any communication session and that decision is stable,
Communication management can transition to an inactive communication state.

3.3.1.2.2.3.3.2.1 COMM_ENABLED State

Communication management will determine if there are any ECU conditions prohibiting communication
activation following a local or remote activation request. Once it confirms communication is allowed
the ECU will begin fully communicating. If the ECU determines conditions no longer exist requiring

GM Confidential ©2017 General Motors LLC. All Rights Reserved

 Document Name:

CAN Communication Strategy Specification

Approved By: File Reg no Info Class

GB5200_CAN_Communication_Strategy_Specification.do
CAN Strategy Development Team
cx
GB5200 II

Issued by: Date Issue Page

Katrina Schultz 11/30/2017 20.20.137 39 (75)

communications, e.g. local and remote activation request are no longer true, while waiting for
communication allowed confirmation, the ECU may return to a communication inactive state.

ECU shall transition to full communications capability as long as there are no ECU conditions prohibiting
communication activation and either a local activation has been detected or a remote wakeup was
processed. [GBCCS612]

ECU shall activate all CAN channels needed to support the activating communication session once the
decision to enter full communications has been made. [GBCCS613]

ECU shall detect that communication activation requests have been canceled before the decision to
enter full communications has been made and return to a communications inactive state. [GBCCS614]
3.3.1.2.2.3.3.2.2 COMM_PREPARE_TO_SLEEP State
Communication management allows the ECU to stabilize before for deactivating communications. If
communication requests are received during this stabilization time, the ECU will return to fully
communicating. Once the stabilization period has expired network coordination will be notified that the
bus is asleep.

ECU shall detect that conditions for resuming full communications has occurred while waiting for the
bus sleep timer to expire and reactivate all CAN channels needed to support the activating
communication session. [GBCCS617]

ECU shall detect that a diagnostic communication session became active while waiting for the bus sleep
timer to expire and reactivate all CAN channels needed to support the diagnostic communication
session. [GBCCS618]

ECU shall prepare for deactivated communications once the decision to go to sleep has stabilized (bus
sleep timer has expired). [GBCCS619]
3.3.1.2.2.3.3.2.3 COMM_ACTIVE State
Fully active communication will allow the ECU to transmit and receive signals based on active
communication session(s). Communications remains active for a minimum amount of time.
Communications remains active as long as there is an active communication or diagnostic session. Once
all communication and diagnostic sessions become inactive the ECU prepares for inactive
communications and waits a period of time to transition in case any new communication sessions
become active.

ECU shall prepare for inactive communications by entering a stabilization state after detecting the
minimum network activation period has lapsed, that there are no active partial networks, no locally

GM Confidential ©2017 General Motors LLC. All Rights Reserved

 Document Name:

CAN Communication Strategy Specification

Approved By: File Reg no Info Class

GB5200_CAN_Communication_Strategy_Specification.do
CAN Strategy Development Team
cx
GB5200 II

Issued by: Date Issue Page

Katrina Schultz 11/30/2017 20.20.137 40 (75)

active or remotely active partial network requests to be processed, and no active diagnostic
communication sessions. [GBCCS622]

3.3.2 Network Management

Network management is the process within Communication management that monitors for conditions
to activate or deactivate a particular communication session.

More than one communication session can be active and managed at any time. All vehicle network
signals are not required to participate in all communication sessions. Operating the communication
network “in parts” e.g. requiring only those signals assigned to a particular communication session to
actively participate, is supported. The subset of the network’s signals transmitted and received in
support of a communication forms a partial network.

Network management controls which ECUs must be active to participate in a particular partial network.
Network management will only activate the ECUs which have signals assigned to the particular partial
network. The set of ECUs assigned to participate in a partial network form a partial network cluster.

Network management controls which set of signals are to be transmitted and received while the partial
network is active. Partial network cluster members responsible for transmitting signals will be
supervised by ECUs relying on their data.

Activating ECUs will follow an activation process to determine when a partial network is to become
active. Under the right conditions activating ECUs will wakeup and notify all partial network cluster
members which partial network is to become active. Activating ECUs will transmit a Network
Management Frame to notify partial network cluster members which partial networks are being
activated. Activating ECUs will continue to transmit the Network Management Frame indicating the
partial network is active as long as the conditions requiring the partial network are true.

Activated ECUs will follow a process to determine when it should actively participate in a partial
network. Activated ECUs monitor the network for wakeups and interpret all received Network
Management Frames to determine if any one of its assigned partial networks have been activated.

Partial networks are not switched off but rather timeout. Each partial network has a timeout timer
associated with it within all partial network cluster members. All partial network cluster members
service the partial network timeout timer based on the Network Management Frame. Activating ECUs
start and reset their partial network timeout timer when transmitting a Network Management Frame
indicating the partial network is active. Activated ECUs start and reset their partial network timeout
timer whenever a Network Management Frame from any channel is received indicating the partial
network is active. The partial network timeout timer is not reset but continues to countdown whenever

GM Confidential ©2017 General Motors LLC. All Rights Reserved

 Document Name:

CAN Communication Strategy Specification

Approved By: File Reg no Info Class

GB5200_CAN_Communication_Strategy_Specification.do
CAN Strategy Development Team
cx
GB5200 II

Issued by: Date Issue Page

Katrina Schultz 11/30/2017 20.20.137 41 (75)

the Network Management Frame is transmitted or received indicating that partial network is no longer
required.

When the partial network is no longer needed, the activating ECU sets the appropriate PNI Bit to zero.
As long as no other ECU is activating the partial network, the partial network will eventually time out
within all partial network cluster members and become inactive.

The following figure is included here to show the relationship of Network management within
Communication management.

COMM_MANAGEMENT_ACTIVE

COMM_MANAGEMENT_MONITOR
Detect no PASSIVE_NETWORK_REQUEST and
no ACTIVE_NETWORK_REQUEST /
Set COMM == NO_COMM;
Determine COMM_ALLOWED

COMM_ENABLED
ComM Request Pending State
NM_COORDINATION_MONITOR_ACTIVE

Expired WAIT_BUS_SLEEP_TIMER /
Set COMM == NO_COMM;
NETWORK_MANAGEMENT_ACTIVE

Detect COMM = FULL_COMM_REQ and

COMM_ALLOWED / Set BUS_SLEEP;
Set COMM == FULL_COMM;
Activate CAN channel(s);

COMM_PREPARE_TO_SLEEP
ComM Ready Sleep State

Detect COMM = FULL_COMM or

DCM_REQ = ACTIVE /
Activate CAN channel(s);
Detect All PN()_LOCAL_REQ = DEACTIVE and
All PN()_REMOTE_REQ = DEACTIVE and
All PN()_TIMEOUT_TIMER = expired and
DCM_REQ = DEACTIVE and
Expired NETWORK_MODE_MIN_TIMER and
Expired NM_TIMEOUT_TIMER /
Start WAIT_BUS_SLEEP_TIMER;

COMM_ACTIVE
ComM Full Communication State

Figure 6: Communication Session Management

3.3.2.1 NETWORK_MANAGEMENT_ACTIVE
While network management is active conditions for activating and deactivating partial networks will be
monitored and reacted, remote activation requests received within Network Management Frames will

GM Confidential ©2017 General Motors LLC. All Rights Reserved

 Document Name:

CAN Communication Strategy Specification

Approved By: File Reg no Info Class

GB5200_CAN_Communication_Strategy_Specification.do
CAN Strategy Development Team
cx
GB5200 II

Issued by: Date Issue Page

Katrina Schultz 11/30/2017 20.20.137 42 (75)

be processed, and local activation requests will be announced by transmitting Network Management
Frames.

NETWORK_MANAGEMENT_ACTIVE contains three concurrent processes to manage these activities:

REMOTE_ACTIVATION_MONITOR_ACTIVE is responsible for monitoring the Network Management

Frame for partial network state changes that involve the ECU,

NM_FRAME_TX_MANAGEMENT_ACTIVE is responsible for scheduling the Network Management

Frame for transmit, and

PARTIAL_NETWORK_MANAGEMENT_MONITOR is responsible for processing activation and

deactivation of particular communication sessions, partial networks.

The following figure contains the NETWORK_MANAGEMENT_ACTIVE logic.

GM Confidential ©2017 General Motors LLC. All Rights Reserved

 Document Name:

CAN Communication Strategy Specification

Approved By: File Reg no Info Class

GB5200_CAN_Communication_Strategy_Specification.do
CAN Strategy Development Team
cx
GB5200 II

Issued by: Date Issue Page

Katrina Schultz 11/30/2017 20.20.137 43 (75)

NETWORK_MANAGEMENT_ACTIVE

PARTIAL_NETWORK_MANAGEMENT_MONITOR

PN( )_INACTIVE
PNC No Communication

Detect PASSIVE_NETWORK_REQUEST and

Detect ACTIVE_NETWORK_REQUEST and
PN()_REMOTE_REQ = ACTIVE /
PN()_LOCAL_REQ = ACTIVE /
Activate PDU group(s);
Set PN() in NM_FRAME;
Activate Supervision;
Activate PDU group(s);
REMOTE_ACTIVATION_MONITOR_ACTIVE

NM_FRAME_TX_MANAGEMENT_ACTIVE

Activate Supervision;
Start PN()_TIMEOUT_TIMER;
Start NM_TIMEOUT_TIMER;
Set COMM == FULL_COMM_REQ;

Detect PASSIVE_NETWORK_REQUEST and

PN()_REMOTE_REQ = ACTIVE /
Activate PDU group(s); Expired PREPARE_PNC_SLEEP_TIMER
Activate Supervision;
Stop PREPARE_PNC_SLEEP_TIMER;
PN( )_REMOTELY_ACTIVACTED
PNC Ready Sleep State

Detect ACTIVE_NETWORK_REQUEST and

PN()_LOCAL_REQ =ACTIVE /
Set PN() in NM_FRAME; Expired PN()_TIMEOUT_TIMER /
Activate PDU group(s); Set PN()_REMOTE_REQ == DEACTIVE;
Activate Supervision; Deactivate PDU group(s);
Start PN()_TIMEOUT_TIMER; Deactivate Supervision;
Start NM_TIMEOUT_TIMER; Start PREPARE_PNC_SLEEP_TIMER;
Set COMM == FULL_COMM_REQ;

Detect PN()_LOCAL_REQ = DEACTIVE /

Reset PN() in NM_FRAME;

PN( )_LOCALLY_ACTIVATED
PNC Requested State

Figure 7: Partial Network Management

3.3.2.1.1 REMOTE_ACTIVATION_MONITOR_ACTIVE
Partial network cluster members notify each other when they activate and deactivate partial networks
by transmitting a Network Management Frame. All ECUs in the network monitor the Network
Management Frame and process the partial network state changes.

The following figure contains the REMOTE_ACTIVATION_MONITOR_ACTIVE logic.

GM Confidential ©2017 General Motors LLC. All Rights Reserved

 Document Name:

CAN Communication Strategy Specification

Approved By: File Reg no Info Class

GB5200_CAN_Communication_Strategy_Specification.do
CAN Strategy Development Team
cx
GB5200 II

Issued by: Date Issue Page

Katrina Schultz 11/30/2017 20.20.137 44 (75)

REMOTE_ACTIVATION_MONITOR_ACTIVE

AWAITING_NM_FRAME_RECEPTION

Detect NM_FRAME_RECEPTION and

PN()_ACTIVATED_REQ /
Set PASSIVE_NETWORK_REQUEST;
Set PN()_REMOTE_REQ == ACTIVE;
Start NM_TIMEOUT_TIMER;
Start PN()_TIMEOUT_TIMER;

Figure 8: Remote Activation

ECU shall have a dedicated timeout timer for each partial network it has been assigned to participate
within. [GBCCS645]

ECUs shall receive all transmitted Network Management Frames regardless of network bandwidth
loading. [GBCCS646]

ECUs shall process all received Network Management Frames. [GBCCS647]

ECU shall interpret the received Network Management Frames to determine if any remote ECU requires
a partial network it has been assigned to be active. [GBCCS648]

ECU shall service the specific partial network timeout timer when it has determined a remote ECU
requires a partial network it has been assigned to be active. [GBCCS649]

3.3.2.1.2 NM_FRAME_TX_MANAGEMENT_ACTIVE
Network Management Frames are transmitted by partial network activating ECUs to indicate their need
or lack of need to communicate. NM_FRAME_TX_MANAGEMENT_ACTIVE determines when a partial

GM Confidential ©2017 General Motors LLC. All Rights Reserved

 Document Name:

CAN Communication Strategy Specification

Approved By: File Reg no Info Class

GB5200_CAN_Communication_Strategy_Specification.do
CAN Strategy Development Team
cx
GB5200 II

Issued by: Date Issue Page

Katrina Schultz 11/30/2017 20.20.137 45 (75)

network activating ECUs will start and stop transmitting a Network Management Frame and how often
the Network Management Frame will be sent.

The following figure contains the NM_FRAME_TX_MANAGEMENT_ACTIVE logic.

NM_FRAME_TX_MANAGEMENT_ACTIVE

NM_FRAME_TX_INACTIVE

Detect ACTIVE_NETWORK_REQUEST and

GENERATE_WAKEUP

LOCALLY_ACTIVING_PN

CAN NM Repeat Message State

Detect NM FRAME xmit’d /

Start NM_TIMEOUT_TIMER; NM_FRAME_WAKEUP_PATTERN_TX_ACTIVE
Start all PN()_TIMEOUT_TIMER;
xmit NM Message ‘n’ times @ ‘x’ms

/ Start NM_FRAME_CYCLE_OFFSET_TIMER;

WAKEUP_DELAY
CAN NM frame offset time

Expired NM_FRAME_CYCLE_OFFSET_TIMER

NM_FRAME_CYCLIC_TX_ACTIVE
CanNmMsgCycleTime

Expired NETWORK_MODE_MIN_TIMER
Detect ACTIVE_NETWORK_REQUEST and
GENERATE_WAKEUP

Detect NM FRAME xmit’d / Detect all PN()_LOCAL_REQ = DEACTIVE

NORMAL OPERATION
Start NM_TIMEOUT_TIMER;
Start all PN()_TIMEOUT_TIMER; CAN NM Normal Operation State

Figure 9: NM Frame Tx Management

Network Management Frame shall be used in the process of generating a wakeup pattern. [GBCCS654]

Generating a wakeup pattern shall be done fulfilling the requirements in ISO11898-6.

GM Confidential ©2017 General Motors LLC. All Rights Reserved

 Document Name:

CAN Communication Strategy Specification

Approved By: File Reg no Info Class

GB5200_CAN_Communication_Strategy_Specification.do
CAN Strategy Development Team
cx
GB5200 II

Issued by: Date Issue Page

Katrina Schultz 11/30/2017 20.20.137 46 (75)

Rationale: Partial network transceivers have a specific pattern they are expecting to bring them out of a
quiescent state, synchronize internal clocks to the bus, and to satisfy wakeup filtering. [GBCCS1751]

Network Management Frames shall be transmitted cyclically for a predetermined period of time
following the wakeup pattern to notify ECUs which partial network is being activated.

Rationale: Network members require a period of time to react to the wakeup pattern and become
receive ready. To accommodate the range times it may take ECUs to become receive ready, the
Network Management Frame will be transmitted a fixed number of times after generating the wakeup
pattern. [GBCCS1752]

Partial network timeout timers shall be reset and started whenever a Network Management Frame is
transmitted with that particular partial network activated. [GBCCS659]

Network management timeout timer shall be reset and started whenever a Network Management
Frame is transmitted. [GBCCS660]

Network Management Frames shall be transmitted cyclically with a predetermined periodic interval
while the ECU is activating at least one partial network. [GBCCS661]

Network Management Frames shall stop transmitting cyclically when the ECU is no longer activating any
partial networks. [GBCCS662]

3.3.2.1.3 PARTIAL_NETWORK_MANAGEMENT_MONITOR
Each partial network operates independent of one another. Each partial network will have activation
criteria used to transition the partial network from an inactive state to an active state and deactivation
criteria used to transition the partial network from an active state to an inactive state. Local activation
takes precedence over remotely activated. PARTIAL_NETWORK_MANAGEMENT_MONITOR manages
these transitions.

ECU shall have a separate instance of PARTIAL_NETWORK_MANAGEMENT_MONITOR logic for each of

the partial networks it has been assigned to and participates within. [GBCCS665]

3.3.2.1.3.1 PN()_INACTIVE
Partial networks can be activated from within the ECU (locally) or by another ECU (remotely).
Activating ECUs and Activated ECUs wait a synchronization period of time allowing each to become
receive ready prior to enabling signals for transmission and reception. Once activated signals may be
transmitted, received, and supervised.

Partial network shall become locally active once local activation criteria for the partial network has been
met. [GBCCS668]

GM Confidential ©2017 General Motors LLC. All Rights Reserved

 Document Name:

CAN Communication Strategy Specification

Approved By: File Reg no Info Class

GB5200_CAN_Communication_Strategy_Specification.do
CAN Strategy Development Team
cx
GB5200 II

Issued by: Date Issue Page

Katrina Schultz 11/30/2017 20.20.137 47 (75)

Partial network bit in the Network Management Frame shall be set active once the partial network
becomes locally active. [GBCCS669]

Network management shall request full communications once the partial network becomes locally
active. [GBCCS670]

Network management and Partial network timeout timers shall be started once the partial network
becomes locally active. [GBCCS671]

Once the partial network has become locally or remotely activated and a communication
synchronization period has lapsed, PDU groups assigned to the partial networks shall be enabled for
transmit and receive processing. [GBCCS672]

Once the partial network has become locally or remotely activated, supervision for the partial network
shall be enabled for transmit and receive processing. [GBCCS673]

Partial network shall become remotely active once remote activation criteria for the partial network has
been met. [GBCCS674]

3.3.2.1.3.2 PN()_LOCALLY_ACTIVATED
While local activation criteria remain true the partial network remains locally activated. When the ECU
detects local activation criteria is no longer true, it will determine if any other ECU has activated the
partial network before processing deactivation.

Partial network shall no longer be considered locally active once local deactivation criteria for the partial
network has been met. [GBCCS677]

Partial network bit in the Network Management Frame shall be cleared once the partial network is no
longer locally active. [GBCCS678]

ECU shall determine if the partial network is remotely activated before continuing the partial network
deactivation process once the partial network is no longer locally active. [GBCCS679]

3.3.2.1.3.3 PN()_REMOTELY_ACTIVATED
While remote activation criteria remain true and the partial network has not been locally activated, the
partial network remains remotely activated. If the partial network becomes locally activated the partial
network transitions to the locally activated state. When the ECU detects neither remote nor local
activation criteria are true and the partial network timeout timer has expired, it will consider the partial
network deactivated. Once deactivated signals will no longer be transmitted, received, or supervised.
After the partial network has been deactivated for a period of time the partial network cluster will be
considered inactive.

GM Confidential ©2017 General Motors LLC. All Rights Reserved

 Document Name:

CAN Communication Strategy Specification

Approved By: File Reg no Info Class

GB5200_CAN_Communication_Strategy_Specification.do
CAN Strategy Development Team
cx
GB5200 II

Issued by: Date Issue Page

Katrina Schultz 11/30/2017 20.20.137 48 (75)

Partial network shall remain remotely active as long as remote activation criteria for the partial network
are being met. [GBCCS682]

Partial network shall become locally active once local activation criteria for the partial network has been
met. [GBCCS683]

Partial network bit in the Network Management Frame shall be set active once the partial network
becomes locally active. [GBCCS684]

Network management shall request full communications once the partial network becomes locally
active. [GBCCS685]

Network Management and Partial network timeout timer shall be started once the partial network
becomes locally active. [GBCCS686]

Once the partial network has become locally activated, PDU groups assigned to the partial networks
shall be enabled for transmit and receive processing. [GBCCS687]

Once the partial network has become locally activated, supervision for the partial network shall be
enabled for transmit and receive processing. [GBCCS688]

Partial network shall be deactivated once the partial network timeout timer is expired. [GBCCS689]

PDU groups assigned to the partial networks shall be disabled for transmit and receive processing once
the partial network becomes deactivated. [GBCCS690]

Supervision for the partial networks shall be disabled for transmit and receive processing once the
partial network becomes deactivated. [GBCCS691]

Partial network shall become inactive after a stabilization period has lapsed. [GBCCS692]

3.3.2.2 Active Communication

Once an ECU is actively participating in a partial network, it can actively communicate by transmitting
and receiving messages. The ECU will monitor its ability to transmit data without disrupting the network
and react in case an error occurs. The ECU will also respond to tester requests to halt communications.

The following figure contains additional detail of the COMM_ACTIVE state. COMM_ACTIVE contains
three concurrent processes:

BUS_OFF_MONITOR_ACTIVE, responsible for monitoring specific error indications from the CAN
controller

DIAGNOSTIC_COMMAND_MONITOR_ACTIVE, responsible for managing the tester service requests

GM Confidential ©2017 General Motors LLC. All Rights Reserved

 Document Name:

CAN Communication Strategy Specification

Approved By: File Reg no Info Class

GB5200_CAN_Communication_Strategy_Specification.do
CAN Strategy Development Team
cx
GB5200 II

Issued by: Date Issue Page

Katrina Schultz 11/30/2017 20.20.137 49 (75)

COMMUNICATION_ACTIVE, responsible for transmitting and receiving messages on the network

COMM_ACTIVE

COMMUMUNICATION_ACTIVE

TX_ONLINE
Detect FRAME()_Tx_REQ and
FRAME() PDU group(s) = ACTIVE and
SUPERSET_CAL = ENABLED /
TX_MODE = OFFLINE Transmit Frame;
DIAGNOSTIC_COMMAND_MONITOR_ACTIVE
BUS_OFF_MONITOR_ACTIVE

TX_MODE = ONLINE

FRAME() PDU group(s) = ACTIVE and

SUPERSET_CAL = ENABLED /
TX_OFFLINE Start FRAME()_DEADLINE_MONITOR;

RX_ONLINE
Detect FRAME()_Rx and
FRAME() PDU group(s) = ACTIVE and
RX_MODE = OFFLINE / SUPERSET_CAL = ENABLED /
Stop FRAME()_DEADLINE_MONITOR; Start FRAME()_DEADLINE_MONITOR;

RX_MODE = ONLINE and

FRAME() PDU group(s) = ACTIVE and
SUPERSET_CAL = ENABLED /
Start FRAME()_DEADLINE_MONITOR;

RX_OFFLINE

Figure 10: Active Communication

3.3.2.2.1 BUS_OFF_MONITOR_ACTIVE
While actively communicating, the possibility of CAN errors exists. When the CAN hardware detects
these errors, error notifications occur and the errors are managed. BUS_OFF_MONITOR_ACTIVE
contains the logic for processing these notifications. Depending on the error CAN communication may
be suspended in accordance to ISO11898 and for some configurable amount of time thereafter in an

GM Confidential ©2017 General Motors LLC. All Rights Reserved

 Document Name:

CAN Communication Strategy Specification

Approved By: File Reg no Info Class

GB5200_CAN_Communication_Strategy_Specification.do
CAN Strategy Development Team
cx
GB5200 II

Issued by: Date Issue Page

Katrina Schultz 11/30/2017 20.20.137 50 (75)

attempt to limit the faulty ECU’s exposure to the network. Multi-network ECUs will have the ability to
monitor and manage CAN error conditions for each of its CAN channels.

The following figure contains the BUS_OFF_MONITOR_ACTIVE logic.

BUS_OFF_MONITOR_ACTIVE
Detect BUS_OFF_OCCURANCE_COUNTER >= L1_TO_L2 /
Detect ERROR_PASSIVE /
Set BUS_OFF_DELAY_TIME == L2;
Notify ERROR_PASSIVE;
/ Set BUS_OFF_DELAY_TIME == L1;
Reset BUS_OFF_OCCURANCE_COUNTER

AWAITING_BUS_OFF

Detect BUS_OFF/
Notify BUS_OFF;

Detect BUS_OFF_DELAY_TIMEOUT /
Set TX_MODE == ONLINE
Increment BUS_OFF_OCCURANCE_COUNTER;

BUS_OFF_DELAY RESET_DLL
Detect DLL_RESET_COMPLETE / (still observes ISO11898 bus off recovery rules)
Set TX_MODE == OFFLINE

Figure 11: Bus Off Monitor

The ECU shall detect and react to ISO 11898 compliant notifications of “bus off”. [GBCCS704]

When a bus off condition is detected, the application shall be notified. [GBCCS706]

When a bus off condition is detected, the ECU shall reset its DLL suspending communications until
ISO11898 compliant bus off recovery has been observed. [GBCCS707]

ECU shall continue to suspend communications for a configurable amount of bus off delay time.
[GBCCS708]

ECU shall resume communications once bus off delay time has expired. [GBCCS709]

Once the ECU has experienced a configurable amount of bus off conditions the bus off delay time shall
be extended. [GBCCS710]

3.3.2.2.2 DIAGNOSTIC_COMMAND_MONITOR_ACTIVE
ECU must activate communications whenever service/diagnostic requests are received and deactivate
communications once the service/diagnostic request has been responded. If a service/diagnostic

GM Confidential ©2017 General Motors LLC. All Rights Reserved

 Document Name:

CAN Communication Strategy Specification

Approved By: File Reg no Info Class

GB5200_CAN_Communication_Strategy_Specification.do
CAN Strategy Development Team
cx
GB5200 II

Issued by: Date Issue Page

Katrina Schultz 11/30/2017 20.20.137 51 (75)

procedure must be executed and the procedure cannot be reliably executed while the ECU performs its
normal communication, then the ECU’s may receive a request to halt normal communications.
NORMAL_COMM_HALT_MONITOR_ACTIVE is responsible for providing the service that halts and re-
enables normal communication.

The following figure contains the logic of DIAGNOSTIC_COMMAND_MONITOR_ACTIVE:

DIAGNOSTIC_COMMAND_MONITOR_ACTIVE

/DCM_REQ == DEACTIVE;

AWAITING_DCM_COMMAND_REQ

DCM determined Comms needed * /

DCM_REQ == ACTIVE;
Start NM_TIMEOUT_TIMER;

DCM_ ENABLE_ALL_COMM_CH_REQ / DCM_ ENABLE_SPECIFIC_COMM_CH_REQ /

Enable Communications on all channels;** Enable Communications on specific channel(s);**
DCM determined Comms no longer needed or
DCM determined Tester failed supervision * /
DCM_REQ == DEACTIVE;

PROCESSING_DCM_COMMAND

DCM_ DISABLE_ALL_COMM_CH_REQ / DCM_ DISABLE_SPECIFIC_COMM_CH_REQ /

Disable Communications on all channels;** Disable Communications on specific channel(s);**
Expired NM_TIMEOUT_TIMER /
Start NM_TIMEOUT_TIMER;

* Conditional logic managed by Diagnostic Communication Manager (DCM)

** This is managed by the Diagnostic Communication Manager (DCM). DCM will issue the
appropriate function calls to disable and enable communications on the specified channel(s)

Figure 12: Diagnostic Command Monitor

When ECU determines a service/diagnostic session requires active communications, active

communications shall be requested. [GBCCS715]

When ECU determines a service/diagnostic session no longer requires active communications, active
communications shall be rescinded. [GBCCS716]

When ECU detects a request to halt all communication channels, all communication channels shall be
halted.

When ECU detects a request to halt a specific communication channel, the specific communication
channel shall be halted.

GM Confidential ©2017 General Motors LLC. All Rights Reserved

 Document Name:

CAN Communication Strategy Specification

Approved By: File Reg no Info Class

GB5200_CAN_Communication_Strategy_Specification.do
CAN Strategy Development Team
cx
GB5200 II

Issued by: Date Issue Page

Katrina Schultz 11/30/2017 20.20.137 52 (75)

When ECU detects a request to re-enable all communication channels, all communication channels shall
be re-enabled.

When ECU detects a request to re-enable a specific communication channel, the specific communication
channel shall be re-enabled.

3.3.2.2.3 COMMUNICATION_ACTIVE
The ECU is configured with a set of communication messages. The entire set of messages may or may
not apply to all vehicles the ECU can be used within; subsets of messages that can or cannot be actively
communicated or monitored are supported. Messages that are configured in an active subset and have
met their transmit model requirements will be transmitted. Supervision deadline monitors are serviced
upon message reception.

The Payload Signal Initialization Completion Time is the time to transmit all signals assigned to a partial
network at least once when that partial network is activated. This time begins with last frame of the
wakeup pattern.

Activated ECUs and Activating ECUs should complete the transmission of all messages assigned to a
Partial Network within the Payload Signal Initialization Completion Time.

Payload Signal Initialization Completion Time = (A * B * C) / D

A = Maximum number of functional message ids possible in system less any message ids reserved for
diagnostic communication

B = 25% = percentage of ids that can be used in system with 75% bus loading limit

C = Time it takes to transmit a message with an 11 bit header, 8 bytes of data, and worst case bit stuffing

D = Assume 25% of transmits are initial transmits for 500 kbps networks (not repeats due to periodic
transmit model) and 50% for 125 kbps networks

3.3.2.2.3.1 TX_ONLINE
Message transmission is enabled in this state.

TX_MODE shall be ONLINE when full communication capable. [GBCCS725]

ECU shall transmit a message once it has met its transmit model requirements provided it has been
configured for transmit in that vehicle’s configuration and at least one of the message’s assigned partial
networks are active. [GBCCS726]

Communication channel shall disable transmitting capabilities when TX_MODE = OFFLINE. [GBCCS727]

GM Confidential ©2017 General Motors LLC. All Rights Reserved

 Document Name:

CAN Communication Strategy Specification

Approved By: File Reg no Info Class

GB5200_CAN_Communication_Strategy_Specification.do
CAN Strategy Development Team
cx
GB5200 II

Issued by: Date Issue Page

Katrina Schultz 11/30/2017 20.20.137 53 (75)

ECU shall transmit all messages that are configured in an active partial network and have met their
transmit model requirements within the Payload Signal Initialization Completion Time. [GBCCS1499]

3.3.2.2.3.2 TX_OFFLINE
Message transmission is disabled in this state.

Communication channel shall enable transmitting capabilities when TX_MODE = ONLINE. [GBCCS730]

3.3.2.2.3.3 RX_ONLINE
Message reception and deadline monitoring is enabled in this state.

RX_MODE shall be ONLINE when full communication capable. [GBCCS733]

Receive message deadline monitoring shall be active when full communication capable provided it has
been configured for reception in that vehicle’s configuration and at least one of the message’s assigned
partial networks are active. [GBCCS734]

ECU shall receive a message provided it has been configured for reception in that vehicle’s configuration
and at least one of the message’s assigned partial networks are active. [GBCCS735]

ECU shall reset receive message deadline monitoring upon message reception provided it has been
configured for reception in that vehicle’s configuration and at least one of the message’s assigned
partial networks are active. [GBCCS736]

Communication channel shall disable message reception capabilities when RX_MODE = OFFLINE.
[GBCCS737]

Receive message deadline monitoring shall be disabled when RX_MODE = OFFLINE. [GBCCS738]

3.3.2.2.3.4 RX_OFFLINE
Message reception and deadline monitoring is disabled in this state.

Communication channel shall enable reception capabilities when RX_MODE = ONLINE provided at least
one of the ECU’s assigned partial networks are active. [GBCCS741]

Communication channel shall enable Receive message deadline monitoring when RX_MODE = ONLINE
provided at least one of the ECU’s assigned partial networks are active. [GBCCS742]

3.3.2.3 Activation Process

A “typical” communication session, partial network, activation scenario follows this activating process:

When the activating ECU assesses activation criteria to be true it transmits a wakeup pattern to
activate the other partial network cluster members.

GM Confidential ©2017 General Motors LLC. All Rights Reserved

 Document Name:

CAN Communication Strategy Specification

Approved By: File Reg no Info Class

GB5200_CAN_Communication_Strategy_Specification.do
CAN Strategy Development Team
cx
GB5200 II

Issued by: Date Issue Page

Katrina Schultz 11/30/2017 20.20.137 54 (75)

The activating ECU then waits a predefined amount of time to allow the other partial network
cluster members time to react to the wakeup pattern and become receive ready.

Once the wait period lapses the activating ECU assumes that all the other partial network cluster
members are able to receive the Network Management Frame indicating which partial network
is to become active.

Activating ECU transmits the Network Management Frame, indicating which partial network is
to become active.

Once partial network cluster members have received and processed the Network Management
Frame they are able to actively communicate.

Partial network cluster members continue to communicate until the partial network times out.

The following figure illustrates the activation process when the network transitions from inactive to
active.

GM Confidential ©2017 General Motors LLC. All Rights Reserved

 Document Name:

CAN Communication Strategy Specification

Approved By: File Reg no Info Class

GB5200_CAN_Communication_Strategy_Specification.do
CAN Strategy Development Team
cx
GB5200 II

Issued by: Date Issue Page

Katrina Schultz 11/30/2017 20.20.137 55 (75)

Scenario: Completely sleeping network

PN ACTIVATING PN ACTIVATED

covers slow waking

ECUs

Network Management Frame Network Management Frame Network Management Frame

3000ms 3000ms 3000ms

Repeat message count

15 @ 10ms

PN init

Active_Synch_Time
xcvr sync + NM xmit + rcvr’s rdy + 10ms

Activated ECUs rcv rdy

t0 + 60ms

NM Passive_Synch_Time
t0 ECU dependent: 0 - 60ms

Activation criteria xcvr sync

evaluated TRUE 32 edges

Activating ECU xmits wkup

Time in ms 0 20 40 60 80 100 120 140

Activating ECU required to send multiple wakeup messages to satisfy ISO11898-6

NM timer within activating ECU

PN timer 1) PN and NM Timers are reset everytime NM frame xmit’d, 2) NM timer is longer than PN timer since it must stay active whenever any Comm port is active.

Passive_Synch_
Time

Activated ECUs rcv rdy

60ms

NM timer within activating ECU

Activated Activated
PN timer 1) PNTimer resets when NM frame with PN active is rcv’d from any channel, 2) NM timer reset when any NM frame is rcv’d..
ECU wakes ECU sync’s
to NM

Figure 13: Activation process

3.3.2.3.1 Activating ECU Requirements

Activating ECU shall be assigned a set of activation criteria, inputs and conditionals, for each partial
network it activates. [GBCCS754]

Activating ECU shall monitor and assess activation criteria and react when it becomes true (local
activation) by implementation of SUM_PNC. [GBCCS755]

Activating ECU shall set the partial network bit in the Network Management Frame to active (1) once
activation criteria are true. [GBCCS756]

Activating ECU shall transmit a wakeup pattern once PN activation criteria are true. [GBCCS757]

GM Confidential ©2017 General Motors LLC. All Rights Reserved

 Document Name:

CAN Communication Strategy Specification

Approved By: File Reg no Info Class

GB5200_CAN_Communication_Strategy_Specification.do
CAN Strategy Development Team
cx
GB5200 II

Issued by: Date Issue Page

Katrina Schultz 11/30/2017 20.20.137 56 (75)

Activating ECU shall transmit the Network Management Frames cyclically for a predetermined period of
time as the wakeup pattern and to notify ECUs which partial network is being activated.

Rationale: Network members require a period of time to react to the wakeup pattern and become
receive ready. To accommodate the range times it may take ECUs to become receive ready, the
Network Management Frame will be transmitted a fixed number of times. [GBCCS1885]

Activating ECU shall not clear the PN bit for an activated PN until the Repeat Message Time expires.
[GBCCS1886]

Activating ECU shall enable for transmit and receive PDU groups assigned to the partial network after
waiting a predetermined period of time for the other network members to become receive ready.
[GBCCS760]

Activating ECU shall enable supervision for PDU groups assigned to the partial network after waiting a
predetermined period of time for the other network members to become receive ready. [GBCCS761]

Activating ECU shall continue to transmit the Network Management Frame cyclically as long as
deactivation criteria are not true. [GBCCS762]

Activating ECU shall reset the partial network timer each time the Network Management Frame is
transmitted with the partial network bit set active. [GBCCS763]

Activating ECU shall reset the network management timer each time the Network Management Frame is
transmitted with the partial network bit set active. [GBCCS764]

3.3.2.3.2 Activated ECU Requirements

Activated ECU shall be configured to wakeup for all partial networks it participates in and not wakeup up
on the others. [GBCCS766]

Activated ECU shall wakeup and become receive ready in a predefined amount of time following the
reception of a partial network wakeup pattern. [GBCCS767]

Activated ECU shall receive and process Network Management Frames. [GBCCS768]

Activated ECU shall reset the partial network timer each time the Network Management Frame is
received with the partial network bit set active. [GBCCS769]

Activated ECU shall reset the network management timer each time the Network Management Frame is
received with the partial network bit set active. [GBCCS770]

GM Confidential ©2017 General Motors LLC. All Rights Reserved

 Document Name:

CAN Communication Strategy Specification

Approved By: File Reg no Info Class

GB5200_CAN_Communication_Strategy_Specification.do
CAN Strategy Development Team
cx
GB5200 II

Issued by: Date Issue Page

Katrina Schultz 11/30/2017 20.20.137 57 (75)

Activated ECU shall enable for transmit and receive PDU groups assigned to the partial network.
[GBCCS771]

Activated ECU shall enable supervision for PDU groups assigned to the partial network. [GBCCS772]

Activated ECU shall enable the receive PDUs for a Partial Network (PN) each and every time a Network
Management Frame for that PN is received once the Repeat Message State expires. [GBCCS1835]

3.3.3 Transmit / Receive Models

Communication between network members shall consist of transmitting and receiving standard frames
governed by approved interface specifications and of vehicle specific frames both containing approved
standard signals. [GBCCS774]

The following figure summarizes the interfaces uses for transmitting and receiving signals.

GM Confidential ©2017 General Motors LLC. All Rights Reserved

 Document Name:

CAN Communication Strategy Specification

Approved By: File Reg no Info Class

GB5200_CAN_Communication_Strategy_Specification.do
CAN Strategy Development Team
cx
GB5200 II

Issued by: Date Issue Page

Katrina Schultz 11/30/2017 20.20.137 58 (75)

APPL
SUM_xxxx F(x)

Set PN State Transmit Signal

Notify PN State Receive Signal

AUTOSAR
RTE STACK

Com_SendSignal
Com_SendSignalGroup

Com_ReceiveSignal

Com

PduR_ComTransmit

Com_RxIndication

PduR

CanIf_Transmit

PduR_CanRxIndication

CanIf

CAN_Write

CanIf_RxIndication

CANDriver

Figure 14: Transmit / Receive Models

GM Confidential ©2017 General Motors LLC. All Rights Reserved

 Document Name:

CAN Communication Strategy Specification

Approved By: File Reg no Info Class

GB5200_CAN_Communication_Strategy_Specification.do
CAN Strategy Development Team
cx
GB5200 II

Issued by: Date Issue Page

Katrina Schultz 11/30/2017 20.20.137 59 (75)

3.3.3.1 Message Transmission

3.3.3.1.1 Configurations
Message transmission behaviors shall be captured in the Data Dictionary. [GBCCS779]

Signals shall be assigned to Partial Network(s). [GBCCS780]

Signals shall be assigned to Protocol Data Units (PDUs). [GBCCS781]

PDUs shall be assigned to messages. [GBCCS782]

An ECU shall be assigned transmitters of messages. [GBCCS783]

All undefined bits in a frame shall be initialized and transmitted always with the value ‘0’ (zero).
[GBCCS784]

All unused signals in a frame shall be initialized and transmitted always with the value ‘0’ (zero).
[GBCCS785]

3.3.3.1.2 Transmit Conditionals and Confirmations

Messages shall be enabled to transmit when at least one of its assigned Partial Network(s) are active.
[GBCCS787]

Each message containing event triggered signals shall have a configurable minimum delay time (MDT)
that must lapse before a consecutive transmit may occur. [GBCCS788]

Rationale: Messages may have multiple transmit criteria resulting in the message being transmitted
quite often. MDT regulates how often a message will actually be transmitted.

All message transmit requests which occur before the MDT has elapsed shall be satisfied with a single
message transmission which occurs once the MDT has elapsed. [GBCCS790]

Each message shall have a configurable confirmation response capable of notifying successful and
unsuccessful message transmission. [GBCCS791]

Rational: Applications whose operation requires transmission of all signal state transitions must make
sequential transmit requests only after prior states have been successfully transmitted.

3.3.3.1.3 Signal Data

All transmitted messages shall contain the most recently available signal data. [GBCCS794]

Multiple byte signals shall be placed into messages without the possibility of an interrupt occurring
between the writing of each individual byte. [GBCCS795]

GM Confidential ©2017 General Motors LLC. All Rights Reserved

 Document Name:

CAN Communication Strategy Specification

Approved By: File Reg no Info Class

GB5200_CAN_Communication_Strategy_Specification.do
CAN Strategy Development Team
cx
GB5200 II

Issued by: Date Issue Page

Katrina Schultz 11/30/2017 20.20.137 60 (75)

A transmitted signal shall have a configurable power up default value. [GBCCS796]

Signal data shall be transmitted using endianness encoding specified in the Data Dictionary. [GBCCS797]

3.3.3.1.4 Transmit Models

Communication between nodes on the CAN network shall consist exclusively of the message
transmission models Periodic, Event, Periodic+Event, and Poll/Response. [GBCCS800]

3.3.3.1.4.1 Periodic
Periodic messages shall be transmitted at a fixed periodic interval (repetition rate) whenever at least
one of its assigned Partial Network(s) are active (see Figure 15). [GBCCS802]

ECUs shall transmit messages at a periodic rate slower than the specified rate if the ECU software timing
can't meet the specified rate. Examples: transmitting at 12.5 ms instead of 10 ms or 25 ms instead of 20
ms. [GBCCS1887]

Periodic message interval accuracy shall be within ± 10% of the repetition rate measured with the device
in isolation. [GBCCS803]

Periodic messages shall begin cyclic transmission after a specified offset time has lapsed.

Rationale: Offset time provides the network designer an opportunity to stagger the start points of
periodic messages in an effort to avoid transmit burst situations. [GBCCS1757]

Message
Transmission
Enabled

Offset
Time
Periodic Interval Periodic Interval Periodic Interval

Message Message Message Message

Transmit Transmit Transmit Transmit

Note: Message transmissions are triggered at

the end of the Periodic Interval
Figure 15 Periodic Transmit Model

GM Confidential ©2017 General Motors LLC. All Rights Reserved

 Document Name:

CAN Communication Strategy Specification

Approved By: File Reg no Info Class

GB5200_CAN_Communication_Strategy_Specification.do
CAN Strategy Development Team
cx
GB5200 II

Issued by: Date Issue Page

Katrina Schultz 11/30/2017 20.20.137 61 (75)

3.3.3.1.4.1.1 Periodic Transmit Model Guidelines

The Periodic transmit model should be used to transmit signals with:
1. A persistent state for discrete signals (such as Door Ajar Status) or a continuous variable (such as
Engine Speed)
2. Where there is no need to provide message updates for spurious or user initiated events that
could occur between periodic intervals

The Periodic interval should be chosen to ensure that consuming functions’ requirements are met, but
not faster than a transmitting application is capable of producing fresh data.

3.3.3.1.4.2 Event
Event messages shall be transmitted once transmit criteria are evaluated true. (see Figure 16).

Rationale: There are numerous forms of transmit criteria for event messages. Some examples include
but are not limited to:

a) after a certain amount of change has been detected in a signal value (send-on-change),

b) after an enabling condition has evaluated true and a timer has elapsed (periodic-when-enabled).
[GBCCS1758]

Consecutive transmissions of an event message shall occur once the MDT has lapsed. [GBCCS812]

Event Event Event Event Event

Min Delay Time Min Delay Time Min Delay Time

Message Message Message Message

Transmit Transmit Transmit Transmit
Note: All message transmissions triggered before the
Minimum Delay Time (MDT) expires are satisfied by
a single transmission.
Figure 16 Event Transmit Model

3.3.3.1.4.2.1 Event Transmit Model Guidelines

The Event transmit model should be used for signals with:
1. No persistent state (such as Touch Pad Key Pressed)

GM Confidential ©2017 General Motors LLC. All Rights Reserved

 Document Name:

CAN Communication Strategy Specification

Approved By: File Reg no Info Class

GB5200_CAN_Communication_Strategy_Specification.do
CAN Strategy Development Team
cx
GB5200 II

Issued by: Date Issue Page

Katrina Schultz 11/30/2017 20.20.137 62 (75)

2. Where there is no need (or value) in retransmitting a signal if a receiver may have missed the
message reception
3. Where the operator is in the loop

The Minimum Delay Time should be chosen to ensure that consuming functions’ requirements are met,
but not faster than a transmitting application is capable of producing fresh data.

3.3.3.1.4.3 Periodic+Event
Periodic+Event messages shall have the transmit characteristics of both the Periodic transmit model and
the Event transmit model. [GBCCS1017]

Consecutive transmissions of a Periodic+Event message shall occur once the MDT has lapsed.
[GBCCS1018]

Periodic+Event message MDT shall be less than the periodic interval minus its negative tolerance.
[GBCCS1019]

3.3.3.1.4.3.1 Periodic + Event Transmit Model Guidelines

The Periodic + Event transmit model should be used for signals with:
1. A persistent state for discrete signals (such as Door Ajar Status) or a continuous variable (such as
Engine Speed)
2. Where there is a need to provide message updates for spurious or user initiated events that could
occur between periodic intervals
3. Where there is value in retransmitting a signal if a receiver may have missed the message
reception

The Periodic Interval and Minimum Delay Time should be chosen to ensure that consuming functions’
requirements are met, but not faster than a transmitting application is capable of producing fresh data.

3.3.3.1.4.4 Poll/Response
Response message shall be transmitted once poll message has been received and data for response
message is ready for transmit. [GBCCS1020]

3.3.3.1.4.4.1 Poll/Response Transmit Model Guidelines

The Poll/Response transmit model is typically used for UDS Diagnostic messages. However, more
generally it is useful to think of this transmit model as a way to require a functional acknowledgement to
a received message.

GM Confidential ©2017 General Motors LLC. All Rights Reserved

 Document Name:

CAN Communication Strategy Specification

Approved By: File Reg no Info Class

GB5200_CAN_Communication_Strategy_Specification.do
CAN Strategy Development Team
cx
GB5200 II

Issued by: Date Issue Page

Katrina Schultz 11/30/2017 20.20.137 63 (75)

3.3.3.1.5 Gateway Transfer models

A gateway shall be configured to transfer wakeup requests, partial network management data and
signal data using one or more of the defined transfer models. [GBCCS823]

A gateway shall be configured in AUTOSAR terminology as an Active PNC Gateway. [GBCCS1888]

3.3.3.1.5.1 Bridging data (A)  (A)

Frames containing signals are received on one network and are re-broadcast on another network of the
same protocol, with essentially the same form (ex. same CAN Id, same data). Bridging data transfer
model results in a One-to-One relationship with data received to data transmitted.

Functional behavior:

Input:

Frame with signals to be bridged.

f(x):

Processing:

Transferring from one network to another done at frame level not signal level.

Output:

Frame with signals passed exactly how received on the destination network.

3.3.3.1.5.2 Routing data (A)  (A)

A frame with signals is received on one network and is re-broadcast on another network, which is not
necessarily the same protocol, with the option to modify network information (source id, etc.), not data
(ex. received 11 bit msg, xmit 29 bit msg). All data is sent, not modified. Routing data transfer model
results in a One-to-One relationship with data received to data transmitted.

Functional behavior:

Input:

Frame with signals to be routed.

f(x):

GM Confidential ©2017 General Motors LLC. All Rights Reserved

 Document Name:

CAN Communication Strategy Specification

Approved By: File Reg no Info Class

GB5200_CAN_Communication_Strategy_Specification.do
CAN Strategy Development Team
cx
GB5200 II

Issued by: Date Issue Page

Katrina Schultz 11/30/2017 20.20.137 64 (75)

Processing:
Apply appropriate header info or “carrier” data to the original frame for the network(s) where
it is re-broadcast.

Transferring from one network to another network is done at frame level not signal level.

Ouput:

Frame with signals passed exactly how received on the destination network(s).

3.3.3.1.5.3 Repackage data (A,B,C,D,E)  (A), (D,C)

A frame with signals is received on one network and one or more of these signals are broadcast in one
or more frames on another network (Distribution). Resultant frames may contain a subset of the
original data, perhaps packed in different order. Any data that is repackaged is not modified.
Repackaging data transfer model results in a One-to-Many relationship with data received to data
transmitted.

Example: One frame is received with 5 parameters, FRAMExx:(A,B,C,D,E). Two frames are transmitted
on a different network each containing some signals from the original frame: FRAMEyy:(A) and
FRAMEzz:(D,C).

Functional behavior:

Input:

Frame with signals to be broadcast.

f(x):

Processing:
Application gets signal from one network, puts it onto destination network

Output:

Signals are broadcast in appropriate frames on the destination network.

3.3.3.1.5.4 Assemble data (A), (B)  (A,B)

Signals from two or more frames are received on one network, possibly from different sources and are
aggregated into a single frame that is sent on another network (Combine). The resultant frame may
contain a subset of the original data, perhaps packed in different order. Any data that is assembled is
not modified. Assembled data transfer model results in a Many-to-One relationship with data received
to data transmitted.

GM Confidential ©2017 General Motors LLC. All Rights Reserved

 Document Name:

CAN Communication Strategy Specification

Approved By: File Reg no Info Class

GB5200_CAN_Communication_Strategy_Specification.do
CAN Strategy Development Team
cx
GB5200 II

Issued by: Date Issue Page

Katrina Schultz 11/30/2017 20.20.137 65 (75)

Example: Two frames are received from different sources FRAMEyy:(A,B,C) and FRAMEzz:(D,E,F). One
frame is transmitted FRAMExx:(C,F,E).

Functional behavior:

Input:

Frames with signals to be broadcast.

f(x):

Processing:
Application gets signals from one network, puts them onto destination network

Output:

Signals are combined with others and broadcast in appropriate frames on the destination
network.

3.3.3.1.5.5 Assemble & Repackage (A,B), (C,D)  (A), (B,D), (C)

Combines transfer models repackage and assemble (as defined above). Signals from two or more
frames are received on one network and packaged into two or more different frames and broadcast on
another network. The resultant frames may contain a subset of the original data, perhaps packed in
different order. Any data that is repackaged or assembled is not modified. Assemble & Repackage data
transfer model results in a Many-to-Many relationship with data received to data transmitted.

Example: Two frames are received FRAMExx:(A,B) and FRAME:(C,D). Data is distributed, combined, and
transmitted in three new frames FRAMEaa:(A), FRAMEbb:(B,D), and FRAMEcc:(C)

Functional behavior:

Input:

Frames with signals to be broadcast.

f(x):

Processing:
Application gets signals from one network, puts them onto destination network

Output:

GM Confidential ©2017 General Motors LLC. All Rights Reserved

 Document Name:

CAN Communication Strategy Specification

Approved By: File Reg no Info Class

GB5200_CAN_Communication_Strategy_Specification.do
CAN Strategy Development Team
cx
GB5200 II

Issued by: Date Issue Page

Katrina Schultz 11/30/2017 20.20.137 66 (75)

Signals are combined and distributed with others in appropriate frames on the destination
network.

3.3.3.1.5.6 Transforming Data (A)  (A’)

A signal is received on one network and sent on another network in a different representation (ex.
scaled differently). Transforming data transfer model results in a One-to-One relationship with data
received to data transmitted.

Functional behavior:

Input:

Frame with signal to be transformed.

f(x):

Processing:
Application gets signal from network

Application executes a specified transform function.

Application puts result onto destination network.

Output:

Resultant signal is broadcast in appropriate frame on the destination network.

3.3.3.1.5.7 Synthesized data (A,B)  f(A,B)

Signals that exist on a network are used to create a new signal that didn’t exist on that network.
Synthesized data transfer model results in the synthesized signal being broadcast on the appropriate
network.

Example: Receive two individual wheel speeds, calculate and transmit an averaged wheel speed.

Functional behavior:

Input:

Frame(s) with signals needed for synthesizing.

f(x):

GM Confidential ©2017 General Motors LLC. All Rights Reserved

 Document Name:

CAN Communication Strategy Specification

Approved By: File Reg no Info Class

GB5200_CAN_Communication_Strategy_Specification.do
CAN Strategy Development Team
cx
GB5200 II

Issued by: Date Issue Page

Katrina Schultz 11/30/2017 20.20.137 67 (75)

Processing:
Application gets signals from network

Application executes a specified function synthesizing a result.

Application puts result onto destination network.

Output:

Resultant signal is broadcast in appropriate frame on the destination network.

3.3.3.1.5.8 Synthesize Metadata

Status information for received signal(s) (as opposed to the signal(s) itself) is synthesized. Some data
may be received from status signals (validity, mask, etc) and some may be from indirect sources
(supervision failures, no signal received, data not initialized, etc). Synthesized Metadata transfer model
results in the synthesized status information signal being broadcast on a different network.

Functional behavior:

Input:

Direction on how to gather information about the signal.

f(x):

Processing:
Application performs analysis on information about the signal

Application executes a specified function synthesizing a result.

Application puts result onto destination network.

Output:

Resultant signal is broadcast in appropriate frame on the destination network

3.3.3.2 Message Reception

3.3.3.2.1 Configurations
Message reception behavior shall be captured in the Data Dictionary. [GBCCS911]

Signals shall be assigned to Partial Network(s). [GBCCS912]

Signals shall be assigned to Protocol Data Units (PDUs). [GBCCS913]

GM Confidential ©2017 General Motors LLC. All Rights Reserved

 Document Name:

CAN Communication Strategy Specification

Approved By: File Reg no Info Class

GB5200_CAN_Communication_Strategy_Specification.do
CAN Strategy Development Team
cx
GB5200 II

Issued by: Date Issue Page

Katrina Schultz 11/30/2017 20.20.137 68 (75)

PDUs shall be assigned to messages. [GBCCS914]

ECUs shall be assigned receivers of signals. [GBCCS915]

3.3.3.2.2 Reception capabilities, conditionals, and confirmations

The ECU shall have the capability to receive and process all CAN messages it has been assigned
regardless of when they are transmitted on the network and network bandwidth loading.

Rationale: The ECU may be designed to receive a set of messages into a single CAN object. The ECU
must be capable of emptying the receive buffer quick enough to avoid an overrun condition. Since
messages are transmitted asynchronously, operating conditions may exist where all the messages
present on the network during 100% network bandwidth utilization must be received by the ECU.
[GBCCS1767]

The ECU shall have a configurable notification capable of indicating when an overrun condition has
occurred. [GBCCS919]

The ECU shall discard, without processing, any received REMOTE FRAME messages it does not explicitly
support. [GBCCS920]

The ECU shall discard, without processing, any received EXTENDED IDENTIFIER messages it does not
explicitly support. [GBCCS921]

The ECU shall receive a message with more data bytes than expected, but shall only process the signals
it was configured to receive. [GBCCS925]

The ECU shall discard a message with less data bytes than expected. The signals in the shorter than
expected message will not be processed. [GBCCS1286]

3.3.3.2.3 Signal Data

Multiple byte signals shall be retrieved from messages without the possibility of an interrupt occurring
between the retrieval of each individual byte. [GBCCS927]

A received signal shall have a configurable power up default value. [GBCCS928]

3.3.3.2.4 Data Validation

Received signals shall be checked using all or a subset of the following procedures to determine whether
the received signal value may be used by the application. [GBCCS930]

The assigned PN for the signal shall be active. [GBCCS1711]

The related Mask signal, if applicable, shall be set to "Use Data". [GBCCS1712]

GM Confidential ©2017 General Motors LLC. All Rights Reserved

 Document Name:

CAN Communication Strategy Specification

Approved By: File Reg no Info Class

GB5200_CAN_Communication_Strategy_Specification.do
CAN Strategy Development Team
cx
GB5200 II

Issued by: Date Issue Page

Katrina Schultz 11/30/2017 20.20.137 69 (75)

Signal supervision, if applicable, shall not have detected a deadline monitoring failure. [GBCCS1714]

The Security Check, if applicable, shall not have detected a failure. [GBCCS1715]

The Safety Check, if applicable, shall not have detected a failure. [GBCCS1716]

The related Validity signal, if applicable, shall be set to "Valid". [GBCCS1717]

3.3.3.2.5 Signal Supervision

A supervised received signal shall have a configurable reception deadline monitor: signal deadline
monitor. [GBCCS933]

Reception deadline monitor shall have a configurable deadline time.

Rationale: The deadline time value is dependent on the application’s functional response time of the
received signal. The periodic interval of a signal is set to satisfy the application’s functional response
time. Generally an application is tolerant to one missed signal reception. Therefore as a general rule of
thumb the network designer can set the deadline time to a value greater than two times the signal’s
periodic interval, e.g. 2.5 times the slowest possible periodic interval of the signal. [GBCCS1768]

Signal deadline monitoring shall begin whenever at least one of the received signal’s Partial Networks
are active. [GBCCS935]

A supervised received signal shall have failed supervision when not received by a specified deadline, e.g.
a deadline timeout occurs. [GBCCS936]

3.3.3.2.5.1 Self-supervised Signals

A self-supervised received signal shall reset its deadline monitor timer whenever the signal is received.

Note: Deadline monitoring for a self-supervised signal can only be achieved when the message it is
framed within is transmitted with either a Periodic or Periodic+Event transmit model. [GBCCS1769]

3.3.3.2.5.2 Unsupervised Signals

An unsupervised signal shall have neither a deadline monitor nor a deadline missed notification or
substitution specified.

Rationale: Some signals require no failsofting or error recovery processing. Typically these are signals
which fall into one of the following categories: [GBCCS1770]

Operator in the loop (ones where an operator causes the event which triggers a signal for transmit);

Signals that have constant value. For instance, a signal indicating transmission type, which is, sent once
during an ignition cycle, but which cannot change.

GM Confidential ©2017 General Motors LLC. All Rights Reserved

 Document Name:

CAN Communication Strategy Specification

Approved By: File Reg no Info Class

GB5200_CAN_Communication_Strategy_Specification.do
CAN Strategy Development Team
cx
GB5200 II

Issued by: Date Issue Page

Katrina Schultz 11/30/2017 20.20.137 70 (75)

Signals for which the last received value or the power up default is the desired substitute value when
the signal is not received.

3.3.3.2.5.3 Data Failsofting

Data failsofting is the procedure used by an application to adapt when a signal fails supervision or the
source of a signal reports that the sensor has failed.

A received signal shall have a configurable notification capable of indicating when it has failed
supervision. [GBCCS948]

Application shall have a defined data failsofting process to follow when it detects failed signal
supervision for the expected receive signal.

Rationale: Notifying the application when supervision fails allows the application to determine which
applicable data falisofting steps are to be taken. Some examples include… utilizing some other data
signal(s) in the algorithm, execute an alternative algorithm, or apply an application specific substitution
value. [GBCCS1771]

3.3.3.2.6 ECU Supervision

ECUs assigned to receive data from another ECU will require a regularly scheduled message to act as a
“heart beat” from the data source (transmitting ECU). The receiving ECU will use the heart beat to
determine that the data source is actively transmitting data. When receiving ECUs detect the heartbeat
is missing, a notification will be made indicating which ECU failed.

ECUs transmitting data shall transmit at least one periodic message in every partial network it provides
data. [GBCCS953]

ECUs supervising received data sources shall have a configurable reception deadline monitor assigned to
one of the periodic messages being transmitted by the data source in a particular partial network: ECU
deadline monitor. [GBCCS954]

Reception deadline monitor shall have a configurable deadline time.

Rationale: The deadline time value is dependent on the application’s functional response time of the
received signal. The periodic interval of a signal is set to satisfy the application’s functional response
time. Generally an application is tolerant to one missed signal reception. Therefore as a general rule of
thumb the network designer can set the deadline time to a value greater than two times the signal’s
periodic interval, e.g. 2.5 times the periodic interval. [GBCCS955]

ECU deadline monitoring shall begin when the partial network for the monitored periodic message being
transmitted by the data source is active. [GBCCS956]

GM Confidential ©2017 General Motors LLC. All Rights Reserved

 Document Name:

CAN Communication Strategy Specification

Approved By: File Reg no Info Class

GB5200_CAN_Communication_Strategy_Specification.do
CAN Strategy Development Team
cx
GB5200 II

Issued by: Date Issue Page

Katrina Schultz 11/30/2017 20.20.137 71 (75)

A supervised data source shall have failed supervision when a deadline timeout occurs. [GBCCS957]

A configurable notification shall be made in the event a deadline timeout occurs. [GBCCS958]

A Loss of Comm Fault Active signal is a signal used for supervising ECUs that cannot be supervised
directly since they are located on different networks. There will be some signals defined whose purpose
will be to represent the availability of these ECUs on the other networks.

When the gateway detects a signal supervision timeout for the signal which has been assigned for
supervision of a certain ECU, then it shall set the corresponding value of the Loss of Comm Fault Active
signal per the requirements in GB8002. [GBCCS1810]

3.3.4 Communication Deactivation

Communication deactivation involves a sequence of events. Once communication sessions are no
longer needed, Network Management, Communication Management, and ECU Management coordinate
deactivating communications.

3.3.4.1 Shutdown Initiation Event

Shutdown process inherently initiates when no activation criteria for any partial network are true.
However, since there may be additional criteria besides the absence of activation criteria, Activating
ECUs are also assigned to monitor partial network’s deactivation criteria. Once deactivation criteria are
assessed true a partial network begins its process of shutting down. Communication shutdown process
cascades from here.

Refer to LOCAL_ACTIVATION_MONITOR_ACTIVE for deactivation criteria detection processing.

3.3.4.2 Shutdown Network Management Process

Network management shuts down after all partial networks are deactivated. Partial network
deactivation follows a sequence of events. A “typical” partial network deactivation scenario follows this
process:

The activating ECU assesses the deactivation criteria as true and transmits a Network
Management Frame with the appropriate partial network bit set to zero.

If the activating ECU is no longer activating any partial networks it will stop transmitting the
Network Management Frame.

Activating ECU transmitting the Network Management Frame with the partial network set to
inactive, will not reset the partial network timer.

GM Confidential ©2017 General Motors LLC. All Rights Reserved

 Document Name:

CAN Communication Strategy Specification

Approved By: File Reg no Info Class

GB5200_CAN_Communication_Strategy_Specification.do
CAN Strategy Development Team
cx
GB5200 II

Issued by: Date Issue Page

Katrina Schultz 11/30/2017 20.20.137 72 (75)

Partial network cluster members receiving the Network Management Frame with the partial
network set inactive, will not reset the partial network timer.

Partial network cluster members not receiving the Network Management Frame will continue to
count down the partial network timer.

Partial network cluster members continue to communicate and continue to communicate as

long as the partial network is active; partial network timer has not expired.

When the partial network timer expires the partial network is considered inactive.

When the partial network timer expires partial network cluster members will no longer transmit
nor expect to receive signals that were assigned to that partial network.

When all the ECU’s partial networks are inactive network management is no longer active.

After a stabilization period has lapsed with no communication activity communications no

longer requires ECU services allowing it to sleep.

ECU shall disable supervision for PDU groups assigned to the partial network after the partial network
timer expires. [GBCCS1491]

ECU shall disable for transmit and receive PDU groups assigned to the partial network after the partial
network timer expires. [GBCCS1474]

The following figure illustrates the activation process when the network transitions from active to
inactive.

GM Confidential ©2017 General Motors LLC. All Rights Reserved

 Document Name:

CAN Communication Strategy Specification

Approved By: File Reg no Info Class

GB5200_CAN_Communication_Strategy_Specification.do
CAN Strategy Development Team
cx
GB5200 II

Issued by: Date Issue Page

Katrina Schultz 11/30/2017 20.20.137 73 (75)

Comms Timers Relative to one another

NMF (PN1) NMF (PN3)

CAN bus 1 activity

NMF (PN2) NMF (PN3) NMF are transmitted asynchronously but with a
periodic interval set to CanNmMsgCycleTime

CAN bus 2 activity

NMTimer NMTimer is reset to CanNmTimeoutTime whenever any NMF is received

Bus Sleep Timer Bus SleepTimer is set to CanNmWaitBusSleepTime

and is started after NMTimer expires.

PN1Timer PNTimer is reset to CanNmPnResetTime whenever a NMF is received with the PN bit set

Prepare PNC1 Sleep Timer Prepare PNC Sleep Timer is set to ComMPncPrepareSleepTimer
and is started after PN Timer expires.

PN2Timer

Prepare PNC2 Sleep Timer

PN3Timer

Prepare PNC3 Sleep Timer

Figure 20: Network Management Shutdown Process

For details on the network management shutdown process, reference:

LOCAL_ACTIVATION_MONITOR_ACTIVE for processing partial network deactivation criteria.

NM_FRAME_TX_MANAGEMENT_ACTIVE for when Network Management Frame will stop transmitting.

NETWORK_MANAGEMENT_ACTIVE for detecting expired partial network timeout timer.

GM Confidential ©2017 General Motors LLC. All Rights Reserved

 Document Name:

CAN Communication Strategy Specification

Approved By: File Reg no Info Class

GB5200_CAN_Communication_Strategy_Specification.do
CAN Strategy Development Team
cx
GB5200 II

Issued by: Date Issue Page

Katrina Schultz 11/30/2017 20.20.137 74 (75)

3.3.4.3 Communication Deactivated State Entry

Once Network Management is inactive Communication Management sets a NO COMM state and waits
for all of the ECUs networks to sleep. Once all networks are asleep, communication is no longer active.

For details on the communication management shutdown process, reference:

NM_COORDINATION_MONITOR for detecting all bus asleep.

COMM_MANAGEMENT_ACTIVE for setting the NO_COMM state.

ECU_MANAGEMENT_ACTIVE for transitioning from COMM_MANAGEMENT_ACTIVE to

COMM_MANAGEMENT_INACTIVE where communications is considered deactivated.

3.3.5 Error Management

3.3.5.1 Bus Fault Mitigation and Recovery
While actively communicating bus off monitoring and notification are active. Bus off detection is done
as defined in ISO11898. When a bus off is detected the faulty ECU will set a diagnostic trouble code and
prohibit message transmission. Bus off monitoring prohibits the faulty ECU from transmitting while it
recovers from a bus off. The faulty ECU will not receive messages while it recovers from a bus off.

Bus off recovery is done as defined in ISO11898. Bus off monitoring tracks the number of times the
faulty ECU experiences a bus off. When the faulty ECU has exceeded a defined number of bus off
occurrences CAN communication will be prohibited beyond the ISO11898 definition in an attempt to
limit the faulty ECU’s exposure to the network. Bus off recovery will follow once a defined delay period
has lapsed.

ECUs supervising messages from the faulty ECU continue to monitor for message reception and react to
deadline monitor timeouts while the faulty ECU recovers from the bus off.

3.3.5.2 ECU Reset Recovery

If an ECU experiences a power failure (e.g., intermittent power line), or experiences a “running” ECU
reset while participating in an active communication session (partial network), it can re-join any of its
assigned partial networks once the ECU repowers. If the ECU is the activator of the partial network it
will assess the activation criteria and if it is still evaluates true, the partial network activation process will
execute. If the ECU is passively activated, the ECU will initialize the hardware to a state where it can
monitor for remote wakeups. If a wakeup is received, the ECU will transition to a state where the
Network Management Frame can be monitored. As long as the activator of the communication session
still requires communications, e.g. still transmitting the Network Management Frame, upon reception
the ECU will resume participation in the communication session.

GM Confidential ©2017 General Motors LLC. All Rights Reserved

 Document Name:

CAN Communication Strategy Specification

Approved By: File Reg no Info Class

GB5200_CAN_Communication_Strategy_Specification.do
CAN Strategy Development Team
cx
GB5200 II

Issued by: Date Issue Page

Katrina Schultz 11/30/2017 20.20.137 75 (75)

3.3.5.3 Diagnostic Support

3.3.5.3.1 Diagnostic Trouble Codes
GB6001 defines communication specific trouble codes.

Bus off monitoring notifications shall be processed as specified in GB6001. [GBCCS1003]

ECU supervision notifications shall be processed as specified in GB6001. [GBCCS1004]

4 Appendix A
The following conventions are used in the state transition diagrams throughout the document:

State transition labels utilize the character “/” to separate the transition conditional description from
the actions to be taken as a result of the executing the transition.

States that hierarchically contain other state diagrams are referred to as “super-states” or “parent
states”. The states contained within them are called “sub-states” or “child states”.

States that contain multiple state diagrams that execute in parallel are labeled with a “file tab” on the
enclosing state. Such states are called “and-states”.

The parallel activities within an and-state are separated graphically by a dashed line. Each of these
activities starts simultaneously upon entry to the and-state.

The symbol “” is used to denote the default, or initial state. The state diagram begins execution in
this state. This symbol also denotes the starting state for state diagrams contained within and-states or
super-states when a transition occurs to the enclosing and or super state.

An exit condition on a super-state or on an and-state is equivalent to having the same exit condition
applied to every sub-state in the and-state or super-state.

The diagrams contained within a super-state or and-state begin executing (at the default state) when
the enclosing state is entered and stop executing when the enclosing state is exited.

Super-states are shaded gray when their sub-states are graphically represented elsewhere in the
document

Multiple actions taken on a transition are separated by a semi-colon (;).

The symbol “==” is used when variables are assigned values. The symbol “=” is used when a logical
evaluation is being performed.

GM Confidential ©2017 General Motors LLC. All Rights Reserved