SURFACE J2178-1

REV.
MAR1999
VEHICLE
400 Commonwealth Drive, Warrendale, PA 15096-0001
RECOMMENDED Issued 1992-06
PRACTICE Revised 1999-03

Superseding J2178-1 JAN1995

Submitted for recognition as an American National Standard

Class B Data Communication Network Messages—

Detailed Header Formats and Physical Address Assignments

TABLE OF CONTENTS

1. Scope ....................................................................................................................................................... 2

2. References ............................................................................................................................................... 3
2.1 Applicable Publications ............................................................................................................................ 3

3. Definitions................................................................................................................................................. 3

4. Abbreviations and Acronyms.................................................................................................................... 3

5. General Information.................................................................................................................................. 5
5.1 Part 1 Overview ........................................................................................................................................ 5
5.2 In-Frame Response Field Formats........................................................................................................... 6

6. Single Byte Header Messages and Format.............................................................................................. 7

7. Consolidated Header Messages and Format ........................................................................................... 8

7.1 One Byte Form of the Consolidated Header Format ................................................................................ 8
7.2 Three Byte Form of the Consolidated Header Format ............................................................................. 8

8. Data Field Formats ................................................................................................................................. 11

8.1 Functional Data Fields Formats.............................................................................................................. 11
8.2 Physical Data Field Formats................................................................................................................... 14
8.3 Extended Addressing ............................................................................................................................. 15

9. Physical Address Assignments .............................................................................................................. 17

10. Notes ...................................................................................................................................................... 17

10.1. Marginal Indicia ...................................................................................................................................... 17

Appendix A Network Architectures and Header Selection......................................................................................... 18

SAE Technical Standards Board Rules provide that: “This report is published by SAE to advance the state of technical and engineering sciences. The use of this report is entirely
voluntary, and its applicability and suitability for any particular use, including any patent infringement arising therefrom, is the sole responsibility of the user.”

SAE reviews each technical report at least every five years at which time it may be reaffirmed, revised, or cancelled. SAE invites your written comments and suggestions.

QUESTIONS REGARDING THIS DOCUMENT: (724) 772-8512 FAX: (724) 776-0243

TO PLACE A DOCUMENT ORDER; (724) 776-4970 FAX: (724) 776-0790
SAE WEB ADDRESS http://www.sae.org

Copyright 1999 Society of Automotive Engineers, Inc.

All rights reserved. Printed in U.S.A.
 SAE J2178-1 Revised MAR1999

1. Scope— This SAE Recommended Practice defines the information contained in the header and data fields of
non-diagnostic messages for automotive serial communications based on SAE J1850 Class B networks. This
document describes and specifies the header fields, data fields, field sizes, scaling, representations, and data
positions used within messages.

The general structure of a SAE J1850 message frame without in-frame response is shown in Figure 1. The
structure of a SAE J1850 message with in-frame response is shown in Figure 2. Figures 1 and 2 also show the
scope of frame fields defined by this document for non-diagnostic messages. Refer to SAE J1979 for
specifications of emissions related diagnostic message header and data fields. Refer to SAE J2190 for the
definition of other diagnostic data fields. The description of the network interface hardware, basic protocol
definition, the electrical specifications, and the CRC byte are given in SAE J1850.

FIGURE 1— SCOPE OF SAE J2178 FOR A SAE J1850 FRAME WITHOUT IN-FRAME RESPONSE (IFR)

FIGURE 2— SCOPE OF SAE J2178 FOR A SAE J1850 FRAME WITH IN-FRAME RESPONSE (IFR)

SAE J1850 defines two and only two formats of message headers. They are the Single Byte header format
and the Consolidated header format. The Consolidated header format has two forms, a Single Byte form and
a three byte form. This document covers all of these formats and forms to identify the contents of messages
which could be sent on a SAE J1850 network.

This document consists of four parts, each published separately.

SAE J2178-1 (Titled: Detailed Header Formats and Physical Address Assignments) describes the two allowed
forms of message header formats, Single Byte and Consolidated. It also contains the physical node address
range assignments for the typical sub-systems of an automobile.

SAE J2178-2 (Titled: Data Parameter Definitions) defines the standard parametric data which may be
exchanged on SAE J1850 (Class B) networks. The parameter scaling, ranges, and transfer functions are
specified. Messages which refer to these parametric definitions shall always adhere to these parametric
definitions. It is intended that at least one of the definitions for each parameter in this part matches the SAE
J1979 definition.

SAE J2178-3 (Titled: Frame IDs for Single Byte Forms of Headers) defines the message assignments for the
single byte header format and the one byte form of the consolidated header format.

SAE J2178-4 (Titled: Message Definition for Three Byte Headers) defines the message assignments for the
three byte form of the consolidated header format.

-2-
 SAE J2178-1 Revised MAR1999

2. References

2.1 Applicable Publications— The following publications form a part of this specification to the extent specified
herein. Unless otherwise specified, the latest issue of SAE publications shall apply.

2.1.1 SAE P UBLICATIONS— Available from SAE, 400 Commonwealth Drive, Warrendale, PA 15096-0001.

SAE J1213-1— Glossary of Vehicle Networks for Multiplex and Data Communication
SAE J1850— Class B Data Communication Networks Interface
SAE J1930— Electrical/Electronic Systems Diagnostic Terms, Definitions, Abbreviations, and Acronyms
SAE J1979— E/E Diagnostic Test Modes
SAE J2190— Enhanced E/E Diagnostic Test Modes

2.1.2 ANSI/IEEE P UBLICATION— Available from ANSI, 11 West 42nd Street, New York, NY 10036-8002.

ANSI/IEEE 754-1985— IEEE Standard for Binary Floating-Point Arithmetic

3. Definitions

3.1 Data [Data Field]— Data and data field are used interchangeably in this document and they both refer to a
field within a frame that may include bytes with parameters pertaining to the message and/or secondary ID
and/or extended addresses and/or test modes which further defines a particular message content being
exchanged over the network.

3.2 Extended Address— The extended address is a means to allow a message to be addressed to a
geographical location (such as geographic) or zone of the vehicle, independent of any node's physical
address.

3.3 Frame— A frame is one complete transmission of information which may or may not include an In-Frame
Response. The frame is enclosed by the start of frame and end of frame symbols. For Class B networks, each
frame contains one and only one message (see "message" definition below).

3.4 Frame ID— The Frame ID is the header byte for the Single Byte Header format and the one byte form of the
consolidated header format. The definition of the frame ID is found in SAE J2178-3. This header byte defines
the target and source and content of the frame.

3.5 Functional Addressing— Functional addressing allows a message to be addressed or sent to one or more
nodes on the network interested in that function. Functional addressing is intended for messages that may be
of interest to more than a single node. For example, an exterior lamp "off" message could be sent to all nodes
controlling the vehicle exterior lamps by using a functional address. The functional address consists of a
primary ID and may include a secondary ID and may also include an extended address.

3.6 Header [Header Field]— The header (or header field, used interchangeably) is a one or three byte field within
a frame which contains information about the message priority, message source and target addressing,
message type, and in-frame response type.

3.7 In-Frame Response (IFR) Type— The IFR type identifies the form of the in-frame response which is expected
within that message.

3.8 Load— The load command indicates the operation of directly replacing the current/existing value of a
parameter with the parameter value(s) contained in the message.

3.9 Message— A message consists of all of the bytes of a frame excluding the delimiter symbols (SOF, EOD,
EOF, NB).

-3-
 SAE J2178-1 Revised MAR1999

3.10 Modify— The modify command indicates the operation of using the message data parameter value to change
(e.g., increment, decrement, or toggle) the current/existing value.

3.11 Parameter— A parameter is the variable quantity included in some messages. The parameter value, scaling,
offset, units, transfer function, etc., are unique to each particular message. (The assigned parameters are
contained herein.)

3.12 Physical Addressing— Physical addressing allows a message to be addressed to a specific node or to all
nodes or to a non-existent, null node. The information in this message is of relevance only to a particular node,
so the other nodes on the bus should ignore the message, except for the case of the "all nodes" address.

3.13 Primary ID— The primary ID identifies the target for this functional message. This is the primary discriminator
used to group functions into main categories.

3.14 Priority— The priority describes the rank order and precedence of a message. Based upon the SAE J1850,
Class B arbitration process, the message with the highest priority will win arbitration.

3.15 Report— A report indicates the transmission of parametric data values, based on: a change of state; a change
of value; on a periodic rate basis; or as a response to a specific request.

3.16 Request— A request is a command to, or a query for data, or action from another node on the network.

3.17 Response Data— The response data is the information from a node on the network in response to a request
from another node on the network. This may be an in-frame response or a report type of message.

3.18 Secondary ID— The secondary ID (along with the primary ID or Frame ID) identifies the functional target node
for a message. The purpose of the secondary ID field within the frame is to further define the function or action
being identified by the primary ID.

4. Abbreviations and Acronyms

A/C - Air Conditioning

ASC - ASCII Encoded SLOT
BCD - Binary Coded Decimal (BCD) SLOT
BMM - Bit Mapped with Mask SLOT
BMP - Bit Mapped without Mask SLOT
CRC - Cyclic Redundancy Check
CS - Checksum
DTC - Diagnostic Trouble Code
EOD - End of Data
EOF - End of Frame
ERR - Error Detection
EV-ETS - Electric Vehicle Energy Transfer System
EVSE - Electric Vehicle Supply Equipment
HVAC - Heating, Ventilation, Air Conditioning
ID - Identifier
IFR - In-Frame Response
LSB - Least Significant Bit/Byte
MSB - Most Significant Bit/Byte
NB - Normalization Bit
PID - Parameter IDentification (number, NOT the primary ID, (See Section 7)
PKT - Multiple Parameter Packet SLOT
PRN - Parameter Reference Number
SED - State Encoded SLOT

-4-
 SAE J2178-1 Revised MAR1999

SFP - Signed Floating Point (Scientific Notation) SLOT

SLOT - Scaling, Limit, Offset, and Transfer Function (See Section 8)
SNM - 2's Complement Signed Numeric SLOT
SOF - Start of Frame
UNM - Unsigned Numeric SLOT
VIN - Vehicle Identification Number

5. General Information

5.1 Part 1 Overview— The messages defined by this four part document are specified for networks using single
byte headers or consolidated one and three byte headers as specified in SAE J1850. Sections 6 and 7 of SAE
J2178-1 provide the system architecture for the different possible headers used in Class B network
communication (see Appendix A for supporting discussion). Section 8 of SAE J2178-1 defines the data fields
used by the different header byte formats. Section 9 of SAE J2178-1 defines the physical address
assignments.

Figure 3 shows an overview of this part (Part 1) which encompasses the different possible messages and their
component parts.

FIGURE 3— PART 1 OVERVIEW

-5-
 SAE J2178-1 Revised MAR1999

SAE J1850 defines two and only two formats of message headers. They are the Single Byte header format
and the Consolidated header format. The Consolidated header format has two forms, identified by the value of
the H Bit. The two forms are: a one byte form and a three byte form. The information in the header field for
both formats contains target, source, priority and message type information, while the data field contains
additional addressing and/or parametric information and/or diagnostic test modes. This information is explicitly
defined in some headers and implicitly defined in others. Messages defined by this document (Parts 1, 2, 3,
and 4) are classified generally into two types:

a. Requests, that is, commands (load or modify) or queries for data, and
b. Responses, that is, reports or acknowledgments.

When a node generates a request, the target nodes which are responsible for the requested data or function
must respond by reporting the requested information or by performing the requested function. For responses
(that is, reports or acknowledgments), data information that a node responds with may have been previously
requested by another node, or reported by the node when the desired information has changed, or reported by
the node on a periodic basis.

SAE J2178-1 describes the overall structure of messages. In total, parts 1, 2, 3, and 4:

a. Fully define SAE (automotive industry) standard messages.

b. Reserve messages for future SAE standardization.
c. Reserve messages for manufacturers to allocate, which are typically unique or proprietary to that
manufacturer.

In order to comply with this document, implementations need to use the defined messages on SAE J1850
networks in the exact way that they are defined here. However, there are a large number of message codes
that are reserved for each manufacturer to independently allocate.

5.2 In-Frame Response Field Formats— The total number of bytes in the frame (not including frame delimiters) is
12, including the header (1 or 3 depending on header type), data (both in the message and IFR), and single
byte CRC. Therefore, the total number of message and IFR data bytes can be 10 if using a single byte header
or the one byte form of the consolidated header, or 8 bytes if using the three byte form of the consolidated
header.

5.2.1 IN-FRAME RESPONSE TYPE 0— The in-frame response type 0 is used to indicate the form without any in-frame
response.

5.2.2 IN-FRAME RESPONSE TYPE 1— The in-frame response type 1 is a single byte response from a single
responder. The response byte shall be the physical address of a receiver of the message. No CRC byte is
included for this response data.

5.2.3 IN-FRAME RESPONSE TYPE 2— The in-frame response type 2 is a single byte response from multiple
responders. The response byte(s) shall be the physical address of the receiver(s) of the message. No CRC
byte is included for the response data.

5.2.4 IN-FRAME RESPONSE TYPE 3— The in-frame response type 3 is a multiple byte response from a single
responder. The response bytes shall be data (generally not its address) from a single responder. The
second CRC byte is included for the data integrity of the response data. The actual in-frame response data
shall be one byte in length, as a minimum.

Figure 4 illustrates the four IFR types.

-6-
 SAE J2178-1 Revised MAR1999

FIGURE 4— TYPES OF IN-FRAME RESPONSE

6. Single Byte Header Messages and Format— For single byte header messages, the entire byte is used to
define the message identifier (ID) as shown in Figure 5. This allows up to 256 unique message identifiers to be
defined. Standard message identifiers that utilize this header format are found in SAE J2178-3.

FIGURE 5— SINGLE BYTE HEADER

All single byte header messages utilize one of the four in-frame response (IFR) types Figure 4.

-7-
 SAE J2178-1 Revised MAR1999

7. Consolidated Header Messages and Format— The consolidated header format includes both a one byte
form and a three byte form.

7.1 One Byte Form of the Consolidated Header Format— The one byte form utilizes 7 bits for the message
identifier thereby allowing up to 128 distinct Ids. The H bit (bit 4) is always a logic "1" signifying the one byte
form of the consolidated header. Figure 6 illustrates this message header form. Standard message identifiers
that utilize this header form are defined in SAE J2178-3.

FIGURE 6— ONE BYTE FORM OF CONSOLIDATED HEADER

In order to accommodate a one byte header form and a three byte header form on the same network, the
header type bit (H bit) in the first byte of the message has been defined to indicate the header form. This bit is
defined in Table 1.

TABLE 1— H BIT DEFINITION

H Bit Header Byte Form
0 Three Byte Form
1 One Byte Form

All one byte header form messages of the consolidated header format utilize one of the four in-frame response
(IFR) types (see Figure 4).

7.2 Three Byte Form of the Consolidated Header Format— This header form utilizes the first three bytes of the
message. The H bit (bit 4) is always a logic "0" signifying the three byte form. Standard message identifiers
that utilize this header form are defined in SAE J2178-4. The remaining seven bits of the first byte contain
information about priority (PPP) and message type (KYZZ). The second byte contains the target address
information. The target can be either functionally addressed or physically addressed. The third byte contains
the physical address of the source of the message. Arbitration is always resolved by the end of the third byte,
since the source address must be unique. Figures 7 and 8 illustrate this message header form.

FIGURE 7— THREE BYTE FORM OF CONSOLIDATED HEADER

-8-
 SAE J2178-1 Revised MAR1999

FIGURE 8— FIRST BYTE OF THREE BYTE FORM OF CONSOLIDATED HEADER

All three byte header messages utilize one of the four in-frame response (IFR) types (see Figure 4, 4).

7.2.1 PRIORITY/TYPE-BYTE 1— The priority/type byte contains information about priority, in-frame response,
addressing type, and type modifier. Each of the field definitions is described in the following paragraphs.

7.2.1.1 Priority (PPP Bits)— The priority field is three bits in length and immediately proceeds the header type (H)
bit. The priority bit definition is shown in Table 2. The priority bit assignments for a particular message are
manufacturer specific and are not assigned by SAE J2178.

TABLE 2— PRIORITY FIELD ASSIGNMENTS

PPP Bits Priority Level
000 0 Highest
001 1 .
010 2 .
011 3 .
100 4 .
101 5 .
110 6 .
111 7 Lowest

7.2.1.2 Header Type (H Bit)— In order to accommodate a one byte header form and a three byte header form on
the same network, the header type bit (H bit) in the first byte of the message has been defined to indicate
the header form. This bit is defined in Table 3.

TABLE 3— H BIT DEFINITION

H Bit Head Byte Form
0 Three Byte Form
1 One Byte Form

-9-
 SAE J2178-1 Revised MAR1999

7.2.1.3 In-Frame Response (K Bit)— The necessity for in-frame response is encoded into a single bit in the priority/
type byte. This bit definition is shown in Table 4.

TABLE 4— "K" BIT ASSIGNMENTS

K Bit In-Frame Response
0 Required
1 Not Allowed

7.2.1.4 Addressing Type (Y Bit)— Message addressing is encoded with a single bit in the priority/type byte. This
bit definition is shown in Table 5.

TABLE 5— "Y" BIT ASSIGNMENTS

Y Bit Addressing Type
0 Functional
1 Physical

7.2.1.5 Type Modifier (ZZ Bits)— The type modifier is encoded as a two bit field (ZZ) and is used in conjunction
with the in-frame response bit (K) and the address type bit (Y) to define sixteen message types, see Table
6.

TABLE 6— THE SIXTEEN MESSAGE TYPES

Msg Response Addressing IFR
Type KYZZ (K bit) (Y bit) Type Message Type (Name)
0 0000 Required Functional 2 Function
1 0001 Required Functional 1 Broadcast
2 0010 Required Functional 2 Function Query
3 0011 Required Functional 3 Function Read
4 0100 Required Physical 1 Node-to-Node
5 0101 Required Physical — Reserved - MFG
6 0110 Required Physical — Reserved - SAE
7 0111 Required Physical — Reserved - MFG
8 1000 Not Allowed Functional 0 Function Command/Status
9 1001 Not Allowed Functional 0 Function Request/Query
10 1010 Not Allowed Functional 0 Function Ext. Command/Status
11 1011 Not Allowed Functional 0 Function Ext. Request/Query
12 1100 Not Allowed Physical 0 Node-to-Node
13 1101 Not Allowed Physical 0 Reserved - MFG
14 1110 Not Allowed Physical 0 Acknowledgement
15 1111 Not Allowed Physical 0 Reserved - MFG
NOTE 1— Functional addresses for the three byte form of the consolidated header are defined in SAE J2178-4.
Physical address ranges are defined in Section 7 of this part.
NOTE 2— Message types 8 and 9 use functional data format #2 only; message types 10 and 11 use functional data
format #3 only.
NOTE 3— Reserved - SAE indicates reserved for future SAE Committee action. Reserved - MFG indicates that
manufacturers are allowed to allocate these definitions without requiring any commonality between motor
vehicle manufacturers.

-10-
 SAE J2178-1 Revised MAR1999

7.2.2 TARGET ADDRESS-BYTE 2— The second byte of the three byte form of the consolidated header format
contains either a functional or physical target address. The physical address assignments are found in
Section 8 of this part, while functional message address assignments are in SAE J2178-4.

Functional addresses are assigned in pairs where the only difference between the ID values is the least
significant bit (W bit). Figure 9 illustrates the functional target address with W bit.

FIGURE 9— FUNCTIONAL TARGET ADDRESS

The W bit is logic "0" to signify a Command target and logic "1" to signify a Status target. This bit is defined
in Table 7.

TABLE 7— W BIT DEFINITION

W Bit Functional Target Address Type
0 Command
1 Status

7.2.3 SOURCE ADDRESS-BYTE 3— The third byte of the three byte format of the consolidated header format is the
physical address of the source of the message. Physical address assignments are found in Section 9.
These physical address assignments shall be unique for each node of a network.

8. Data Field Formats— In both message header formats, single byte and consolidated, the data field can
usually be encoded in the same way. This section briefly describes the different ways that information can be
formatted in the data field. The data field immediately follows the header field. The number of bytes in this
field will vary, based upon the content of the header field. The maximum data field length is limited by the
requirements of SAE J1850. Because of differences in functionally and physically addressed messages or
with in-frame response data, these cases are defined separately.

8.1 Functional Data Field Formats

8.1.1 FUNCTIONAL DATA FIELD FORMAT 0— One of the functional data field formats is, in fact, no additional bytes of
data (an empty data field). The message consists of the header, error checking byte, and in-frame response
bytes. This is the format used for functional message types 2 and 3. Because the data field does not
actually exist but to allow referencing in other parts of this document, it has been identified as the functional
data field format 0.

8.1.2 FUNCTIONAL DATA FIELD FORMAT 1— In the simplest case including data (format 1), the data field contains
only parametric data. The first byte of the data field in this case contains the most significant byte of data.
The data field must contain one byte as a minimum. Figure 10 illustrates this message format. This data
field format may be used for message types 0 and 1 only.

FIGURE 10— FUNCTIONAL DATA FIELD FORMAT 1

-11-
 SAE J2178-1 Revised MAR1999

8.1.3 FUNCTIONAL DATA FIELD FORMAT 2— In a data field format 2 message, the data field contains a byte which is
used to further define the target function being addressed. In this format type, the data field would appear as
shown in Figure 11. This data format may be used for message types 0, 1, 8 and 9.

FIGURE 11— FUNCTIONAL DATA FIELD FORMAT 2

The secondary address byte consists of a parameter/quantity bit (Q bit) in which binary data (such as, on/off
or yes/no) can be encoded. There is a listing of the possible uses for this bit in SAE J2178-4. The control bit
(C bit) is used to distinguish between an immediate load of data or a modify of the current data for command
messages, or to distinguish between request/report and query message operations. The remaining six bits
specify a secondary ID address. The order of these bits within the secondary address byte is shown in
Figure 12.

FIGURE 12— SECONDARY ADDRESS BYTE FORMAT

In many cases, a single data bit (i.e., the Q bit) is not adequate to define the data parameter being sent. In
this case, the identifier field is followed by an additional data field as illustrated in Figure 13. The
combination of the primary and secondary addresses defines whether additional data is used by that
message.

FIGURE 13— FUNCTIONAL DATA FIELD FORMAT 2, WITH DATA BYTES

8.1.3.1 The Parameter/Quantity Bit (Q bit)— The Q bit is used to represent single, binary values. Refer to SAE
J2178-4 for a list of valid uses for the Q bit.

8.1.3.2 The Control Bit (C bit)— The C bit represents an action or operation to be taken with the associated data
values. Table 8 shows how the W and C bits are used in conjunction with the eight functionally addressed
messages types (0-3, and 8-11) to define a particular message operation.

Modify messages adjust (e.g., increment/decrement) or toggle the state of existing data. Load messages
replace current or existing data. Request messages "ask" for existing status or command data. Report
messages "tell" existing status. Query messages "ask" for the receivers of a message without asking for
the associated data.

-12-
 SAE J2178-1 Revised MAR1999

TABLE 8— MESSAGE OPERATIONS

Msg
Type KYZZ W C Message Type Message Operation
0 0000 0 0 Function Load Command
0 1 Modify Command
1 0 Report Status
1 1 MFG Specific

1 0001 0 0 Broadcast Load Command

0 1 Modify Command
1 0 Report Status
1 1 MFG Specific

2 0010 0 n/a Function Query Command Query

1 n/a Status Query

3 0011 n/a n/a Function Read Not Applicable

8 1000 0 0 Function Command/ Load Command

Status
0 1 Modify Command
1 0 Report Status
1 1 MFG Specific

9 1001 0 0 Function Request/Query Status Request

0 1 Report Acknowledge
1 0 Command Request
1 1 Function Query

10 1010 0 0 Function Ext. Command/ Load Command Extended

Status
0 1 Modify Command Extended
1 0 Report Status Extended
1 1 MFG Specific

11 1011 0 0 Function Ext. Request/ Status Request Extended

Query
0 1 Report Acknowledge Extended
1 0 Command Request Extended
1 1 Function Query Extended

8.1.3.3 The Secondary ID— The secondary identification field is used to further identify the particular function or
operation being addressed by this message. It is used to distinguish a function when the primary ID is not
sufficient, or to define a specific operation to be performed by the function addressed by the primary ID.
These secondary identification addresses are assigned in SAE J2178-3 and SAE J2178-4.

8.1.4 FUNCTIONAL DATA FIELD FORMAT 3— In a data field format 3 message, depending on the particular primary
and secondary ID, the data field may also contain an extended address byte which defines the geographical
location within the vehicle of the target function being addressed. This data field format may be used for
message types 0 and 1 and must be used for message types 10 and 11. In this data field type, the data field
appears as shown in Figure 14.

-13-
 SAE J2178-1 Revised MAR1999

FIGURE 14— FUNCTIONAL DATA FIELD FORMAT 3

The extended address byte is used to determine where, geographically on a vehicle, a particular function is
located. The exact definition of the extended address values can be found in 8.3. The secondary address in
Figure 14 is used as defined in 8.1.3.

As in the other data field formats, a parameter data field may also be needed and in this case it is then
appended to the end of the other identifiers. This format is shown in Figure 15.

FIGURE 15— FUNCTIONAL DATA FIELD FORMAT 3, WITH DATA BYTES

8.1.5 FUNCTIONAL DATA FIELD FORMAT 4— In this data field format message, the data field contains a byte which
defines the diagnostic test mode of the target function being addressed. In this type, the data field would
appear as shown in Figure 16. This data format may be used for message types 0, 1, 8 and 9.

FIGURE 16— FUNCTIONAL DATA FIELD FORMAT 4

The test mode byte is used to determine which diagnostic function is involved. It may be followed by
parameter data fields. In this case, the additional data bytes follow the test mode byte. This format is shown
in Figure 17. This is the format for functionally addressed diagnostic messages such as those found in SAE
J1979.

FIGURE 17— FUNCTIONAL DATA FIELD FORMAT 4, WITH DATA BYTES

8.2 Physical Data Field Formats— The previous section (8.1) defined the data field formats for functionally
addressed messages. This section (8.2) defines the data field formats for physically addressed messages.

8.2.1 PHYSICAL DATA FIELD FORMAT 0— One of the physical data field formats is, in fact, no additional bytes of data
(an empty data field). The message consists of the header, error checking byte, and may be with or without
in-frame response bytes. This is the format used for the acknowledgement message type. This message
type simply confirms to another node that the message has been received correctly. Because this data field
does not actually exist but to allow referencing in other parts of this document, it has been identified as the
physical data field format 0.

-14-
 SAE J2178-1 Revised MAR1999

8.2.2 PHYSICAL DATA FIELD FORMAT 1— Physical data field format 1 is generally associated with the node-to-node
message types. This message type is the one utilized for enhanced E/E diagnostic test modes (see SAE
J2190). This format assumes the three byte form of the consolidated header format. The single byte format
and the one byte form of the consolidated header format are covered in physical data field format 2 (see
8.2.3). Many of the specific diagnostic messages are defined in SAE J2190. This description of the format is
consistent with SAE J2190 but expands the definition to allow the format to be used in other messages as
well. In particular, the manufacturer specific applications of this node-to-node message are expected to
follow this format. The basic format is similar to the functional data field format 4. The format is shown in
Figure 18.

FIGURE 18— PHYSICAL DATA FIELD FORMAT 1

The format will often include data bytes as shown in Figure 19. The contents of the test mode byte indicate
if additional data bytes are used.

FIGURE 19— PHYSICAL DATA FIELD FORMAT 1, WITH DATA BYTES

The physical test mode byte details are shown SAE J2190.

8.2.3 PHYSICAL DATA FIELD FORMAT 2— In order to maximize commonality between the different header byte
formats, the physical data field format 2 is essentially the same as physical data field format 1 with the
insertion of the physical target address byte ahead of the physical test mode byte. This allows the single
byte header format and the one byte form of the consolidated header format to operate consistently with the
three byte header form. The format is shown in Figures 20 and 21 for the two cases, without and with
additional data bytes, respectively.

FIGURE 20— PHYSICAL DATA FIELD FORMAT 2

FIGURE 21— PHYSICAL DATA FIELD FORMAT 2, WITH DATA BYTES

8.3 Extended Addressing— Extended addressing defines an extended (geographical) location in the vehicle.
The upper two bits of the extended address (RR) are used to allow up to four different types of extended
addressing. Table 9 shows these bit assignments.

TABLE 9— EXTENDED ADDRESS TYPES

RR Type
00 Geographical Addressing
01 Reserved - SAE
10 Reserved - MFG
11 Reserved - MFG

-15-
 SAE J2178-1 Revised MAR1999

The extended address format for geographical addressing is encoded as shown in Figure 22.

FIGURE 22— EXTENDED ADDRESSING

The codes XXX = 000 (for rows) and YYY = 000 (for columns) indicate that ALL rows and/or ALL columns are
indicated. In other words, to address all of the items in a specific row, regardless of which column, use XXX =
000. For all items in the same column, independent of which row, use YYY = 000. Using all combinations of
XXX and YYY, there are 64 total geographical zones that can be addressed. Table 10 shows the different
combinations available.

TABLE 10— EXTENDED ADDRESS AREAS

XXX Range YYY Range Description # areas
000 000 ALL Rows and Columns 1
000 001 - 111 ALL Rows x 7 Columns 7
001 - 111 000 ALL Columns x 7 Rows 7
001 - 111 001 - 111 49 Distinct Areas 49

SAE J2178-4 lists the valid extended address assignments based on message.

A map illustrating the 49 zones of the vehicle is shown in Figure 23. It generally represents a top view of the
vehicle and supports both Left/Right and Driver/Passenger side references.

NOTE— Refer to J2178-4 for range of address explanation.

FIGURE 23— EXTENDED ADDRESS MAP

-16-
 SAE J2178-1 Revised MAR1999

9. Physical Address Assignments— The physical address assignment ranges for nodes on a network are
shown in Table 11. It is important to note that node address assignments on any network must be unique. In
other words, no two nodes can have the same physical address assignment.

TABLE 11— NODE PHYSICAL ADDRESS ASSIGNMENTS

Node Category Address (hex) # of Nodes
Powertrain Controllers: 00 - 1F 32

Integration/Manufacturer Expansion 00 - 0F 16
Engine Controllers 10 - 17 8
Transmission Controllers 18 - 1F 8

Chassis Controllers: 20 - 3F 32

Integration/Manufacturer Expansion 20 - 27 8
Brake Controllers 28 - 2F 8
Steering Controllers 30 - 37 8
Suspension Controllers 38 - 3F 8

Body Controllers: 40 - C7 136

Integration/Manufacturer Expansion 40 - 57 24
Restraints 58 - 5F 8
Driver Information/Displays 60 - 6F 16
Lighting 70 - 7F 16
Entertainment/Audio 80 - 8F 16
Personal Communications 90 - 97 8
Climate Control (HVAC) 98 - 9F 8
Convenience (Doors, Seats, Windows, etc.) A0 - BF 32
Security C0 - C7 8

Electric Vehicle Energy Transfer System (EV-ETS) C8 - CB 4

Utility Connection Services (FN#1) C8 1
AC to AC Conversion (FN#2 C9 1
AC to DC Conversion (FN#3) CA 1
Energy Storage Management (FN#4) CB 1

Future Expansion: CC - CF 4
Manufacturer Specific: D0 - EF 32
Off-Board Testers/Diagnostic Tools: F0 - FD 14
All Nodes: FE 1
Null Node: FF 1

10. Notes

10.1 Marginal Indicia— The change bar (l) located in the left margin is for the convenience of the user in locating
areas where technical revisions have been made to the previous issue of the report. An (R) symbol to the left
of the document title indicates a complete revision of the report.

PREPARED BY THE SAE MESSAGE STRATEGY TASK FORCE OF THE SAE VEHICLE NETWORK
FOR MULTIPLEX AND DATA COMMUNICATION STANDARDS COMMITTEE

-17-
 SAE J2178-1 Revised MAR1999

APPENDIX A

NETWORK ARCHITECTURES AND HEADER SELECTION

A.1 Architectures of Networks— A wide variety of network topologies can be envisioned by network designers.
The message structure described in this document is very flexible and useful in exchanging information
between network nodes. The following discussion describes two network architectures that are likely
configurations to use this message definition set:

a. A single network architecture

b. A multiple network architecture

The choice of message definitions to be used for these two network architectures is left to the system designer,
because the selection is application specific. It should be noted that the hardware that supports these two
message structures is generally not interchangeable. It is recommended that care be taken in choosing which
message definition to use because the selection is generally irreversible because of these hardware
limitations.

Consideration must be given by the network designer as to whether a single network architecture or a multiple
network architecture, within the same vehicle, is preferable for that application. For example, a multiple
network architecture could be based on one network optimized around data communication (Class B) protocol
requirements, and another network optimized around sensor type (Class A) multiplexing requirements. The
Class B network may be characterized such that time is a significant characteristic of the protocol where the
functional "broadcast" type of message strategy can most effectively be used. The functional messages
strategy can, if required, define the source or destination of a particular message by making it part of the
message. However, it is unnecessary to designate or specify the source or destination of functional broadcast
type messages. Reception becomes the exclusive responsibility of the receiving node.

A Class A network could handle the vehicle's event-driven multiplexing requirements. A single network
architecture is based on the concept of a network that handles both Class A and B requirements. It should be
clear that both network architectures must be cost effective for the application and the specific nodes on each
network.

In Class B communications, the network consists of the interconnection of intelligent nodes such as: an engine
controller, a body computer, a vehicle instrument cluster, and other modules. Such a network normally does
not significantly reduce the base vehicle wiring but provides an inter-module data communications capability
for distributed processing. The data shared between modules may be repetitive in nature and sometimes
requires handshaking between modules or acknowledgment of data reception. As a result of handling the
repetitive data and response type data, a network can be optimized around functional addressing. Functional
addressing sends data on the network which can be received by one or more nodes without regard to the
physical location of the module but only by their "interest" in those specific functions. In general, the
transmitting node doesn't care which, if any, nodes receive the data it is sending. When physical addressing is
required in a data communications (Class B) network, it is usually for vehicle diagnostic purposes and can be
easily handled without reducing network bandwidth. See Section 7 for a discussion of these two types of
message addressing.

In Class A communications, the network generally consists of the interconnection of limited intelligence nodes,
often simply sensors or actuators. These Class A networks can significantly reduce the base vehicle wiring as
well as potentially remove redundant sensors from the vehicle. The data shared between nodes in this case
are generally event driven in nature. In most vehicles, the number of event driven signals predominates but
they are only needed infrequently. The message to "turn headlamps on," for example, can be easily seen as
event driven.

-18-
 SAE J2178-1 Revised MAR1999

Because these messages are infrequent (only sent once when the signal changes), they generally require
acknowledgment, either within the same message or a separate handshake/response message. Both of these
approaches are supported by SAE J1850 and in this document.

The single network architecture carries both the Class A and Class B messages on one network. The
characteristics of both time critical and event driven messages must be accommodated on a message by
message basis. In general, this level of complexity will need the flexibility of the consolidated header structure.
For some applications, however, the single byte header may be adequate and is in no way limited by this
specification.

The multiple network architecture tends to separate the Class A messages from the Class B messages and
optimize each network and node interface for the specific characteristics of each network Class. The time
critical messages could be exchanged on one network while the event driven messages sent on another. For
example, the data communication (Class B) repetitive messages can be handled on one network and the
sensor and control (Class A) multiplexing requirements on another network. This architecture requires both
networks to work together to achieve the total vehicle network requirements. If information is needed between
the multiple networks, care must be exercised to meet the needs of each of the networks. This concept of
multiple networks is not limited to two, but can be extended to several separate networks, if desired.

A.2 Header Selection— The selection of headers is dependent on a number of factors. Hardware cost is related
to the complexity of interface hardware required, as opposed to level of software required to implement the
system.

The three byte form of the consolidated header offers systems designers advantages over the single byte only
header format. More bits are available for use in assigning message identifiers, priorities, message types, etc.
In addition, the three byte header is not restricted to 256 addresses. The "H" bit of the consolidated header
format is used to indicate the use of one byte or three byte header messages which provides flexibility for
future applications. This consolidated format generally requires increased hardware implementations because
of the variety of message forms allowed. However, because of the increased hardware definition, software
complexity and coding error problems are reduced. The consolidated header format offers the flexibility to
readily handle both Class A and Class B requirements, matching header length to each specific message, as
needed.

The single byte only header format is a simple and efficient method of identifying messages in a Class B data
communications optimized network. This type of header can be simply called the Message Identifier or ID.
The ID becomes the name of the message that is broadcast to all the other nodes on the network. The
message ID concept supports a very easily understood message protocol leading to the utilization of a simple
hardware interface circuit.

The single byte only header format in a Class B data communications environment is required to support a
repetitive message strategy and manage network bandwidth efficiently. The results can yield an average
message length of less than four bytes. Message overhead can be kept small and message latency minimized
to improve the network's capability for handling time critical data. Another resulting feature of this method of
message identification is that arbitration events are reduced (resolved within the first byte) and the need to
carefully assign message priority is reduced.

As in the case of network architectures above, the choice of single byte header format or consolidated header
format is left to the system designer. The choice must be made for each separate network for each application
but this offers the ability to select which characteristic is important for the specific case.

-19-
 SAE J2178-1 Revised MAR1999

Rationale— SAE J2178-1 was revised to include terms applicable to electric vehicles and to agree with SAE
J2293. Minor typographical errors were also corrected.

Relationship of SAE Standard to ISO Standard— Not applicable.

Application— This SAE Recommended Practice defines the information contained in the header and data
fields of non-diagnostic messages for automotive serial communications based on SAE J1850 Class B
networks. This document describes and specifies the header fields, data fields, field sizes, scaling,
representations, and data positions used within messages.

The general structure of a SAE J1850 message frame without in-frame response is shown in Figure 1.
The structure of a SAE J1850 message with in-frame response is shown in Figure 2. Figures 1 and 2
also show the scope of frame fields defined by this document for non-diagnostic messages. Refer to
SAE J1979 for specifications of emissions related diagnostic message header and data fields. Refer to
SAE J2190 for the definition of other diagnostic data fields. The description of the network interface
hardware, basic protocol definition, the electrical specifications, and the CRC byte are given in SAE
J1850.

SAE J1850 defines two and only two formats of message headers. They are the Single Byte header
format and the Consolidated Header format. The Consolidated Header format has two forms, a Single
Byte form and a three byte form. This document covers all of these formats and forms to identify the
contents of messages which could be sent on a SAE J1850 network.

This document consists of four parts, each published separately.

SAE J2178-1 (Titled: Detailed Header Formats & Physical Address Assignments) describes the two
allowed forms of message header formats, single byte and consolidated. It also contains the physical
node address range assignments for the typical sub-systems of an automobile.

SAE J2178-2 (Titled: Data Parameter Definitions) defines the standard parametric data which may be
exchanged on SAE J1850 (Class B) networks. The parameter scaling, ranges, and transfer functions
are specified. Messages which refer to these parametric definitions shall always adhere to these
parametric definitions. It is intended that at least one of the definitions for each parameter in this part
matches the SAE J1979 definition.

SAE J2178-3 (Titled: Frame IDs for Single Byte Forms of Headers) defines the message assignments
for the single byte header format and the one byte form of the consolidated header format.

SAE J2178-4 (Titled: Message Definition for Three Byte Headers) defines the message assignments for
the three byte form of the consolidated header format.

Reference Section

SAE J1213-1— Glossary of Vehicle Networks for Multiplex and Data Communication

SAE J1850— Class B Data Communication Network Interface

SAE J1930— Electrical/Electronic Systems Diagnostic Terms, Definitions, Abbreviations, and Acronyms

SAE J1979— E/E Diagnostic Test Modes

SAE J2190— Enhanced E/E Diagnostic Test Modes

ANSI/IEEE 754-1985— IEEE Standard for Binary Floating-Point Arithmetic

 SAE J2178-1 Revised MAR1999

Developed by the SAE Message Strategy Task Force

Sponsored by the SAE Vehicle Network for Multiplex and Data Communication Standards Committee