Implementing the CAN Calibration Protocol (CCP) in an

SAE J1939 Application

William B. Vlcek

This paper presents the implementation of the CAN Calibration Protocol (CCP) on an
electronic control unit (ECU) using the Society of Automotive Engineers’ (SAE) Rec-
ommended Practice J1939 multiplex communications protocol. SAE J1939 uses a
CAN-based network protocol, to which we added CCP to support calibration and
measurement activities during the development and test of new application software.
The use of a commercially available PC-based tool for calibration and measurement
provided a cost-effective solution to support these capabilities for this development
program.

Introduction ters, or calibrations. There is also a re-

quirement to provide the capability to set
The approach taken in this paper is to first
and change these parameters using a
define the overall task with which we were
service tool. Since this ECU interacts with
presented, then identify the options avail-
other ECUs in heavy-duty truck applica-
able to satisfy the specific challenge dis-
tions, it must support the Society of Auto-
cussed here — providing a cost effective
motive Engineers (SAE) specification
means to calibrate and measure an ECU
J1939 multiplex communications protocol.
in development. This will be followed by a
Other requirements include: monitoring
brief review of the communications proto-
internal operations of the ECU; repro-
cols used, before getting to the discussion
gramming the ECU during its develop-
covering the implementation of our
ment; and providing a way to change cali-
selected solution. The basic task dis-
brations while operating the engine.
cussed in this paper is how we provided
the customer with a solution to their Available Options
requirement to calibrate the application
In considering the alternatives that related
software in their ECU.
to calibration we identified two options: de-
Task Definition velop a calibration system from scratch, or
find a commercially available solution.
Our customer decided to develop their
The analysis of the first option showed the
next generation electronic control unit
cost to design a calibration strategy, to
(ECU). They chose to move from a
develop the ECU’s calibration subsystem
Motorola MC68HC11 microcontroller, with
and counterpart service tool system (PC-
application software in Assembly lan-
based), then implement and test it, could
guage, to a Motorola MC68376 microcon-
have easily exceeded the cost of devel-
troller with the software to be written in
oping the application software it would
"C". We were approached to develop the
support. The continued maintenance of
software due to our familiarity with the
such a proprietary calibration tool could
Motorola family of microcontrollers, and
have been substantial and was not in the
experience with developing and maintain-
plans of this development program.
ing similar automotive software applica-
tions. The second choice, to identify a commer-
cially available solution, was then
The ECU under development is targeted
reviewed. To simplify the communications
to work on a variety of diesel engine appli-
capabilities of the ECU, the solution would
cations, and requires flexibility in the num-
preferably work with an existing protocol
ber and type of the inputs and outputs to
used by heavy-duty truck applications,
be supported. The application contains a
either SAE J1587 or SAE J1939. One
large number of programmable parame-
desire was to identify a CAN-based solu-
tion, which could be made to work with tain 8 data bytes, of which some or all
J1939, and thus allow the ECU to support may be defined. Data bits not currently
only one communications protocol. defined are to be transmitted as “1” and
received as “Don’t Care.” This is to sup-
SAE J1939 Protocol Background
port future definition without affecting
Before discussing the task in more detail, existing applications. The data bytes tend
let us review some background on the to be grouped by function in the message
technologies used. The industries which frames. For example, the message
use large diesel engines — heavy-duty “Electronic Engine Controller #1” (EEC1)
trucks, buses, construction equipment, contains Status_EEC1 (Engine/retarder
and agricultural equipment — participate torque mode), Driver’s demand engine –
in the SAE’s Truck & Bus Electrical and percent torque, Actual engine – percent
Electronics Committee. The Truck and torque, Engine speed, Source address of
Bus Control and Communications Network controlling device for engine control
Subcommittee has developed a family of (which could be a device other than the
specifications for serial data communica- one transmitting this message), and 2 un-
tion over multiplexed wiring. Commonly defined bytes.
known by the SAE specification number,
The diagnostic messages defined in Part
J1939, these specifications define the
73 are recognizable to anyone familiar
complete ISO OSI seven-layer communi-
with On-Board Diagnostics, Phase II (OBD
cations model. The J1939 network
II) as implemented by SAE J1979, E/E
environment operates with shielded,
Diagnostic Test Modes (ISO 15031-5).
twisted pair wire and uses the 29-bit ex-
tended format CAN data frame. The CCP Protocol Background
J1939 family of specifications cover not
The CAN Calibration Protocol (CCP) is a
only the physical layer (Part 11) and data
standard maintained by the ASAP task
link layer (Part 21). It also includes a
force (Arbeitskreis zur Standardisierung
network layer specification (Part 31),
von Applikationssystemen; English trans-
definition of all application messages and
lation of this is Standardization of Applica-
their data content (Part 71), and definition
tion/Calibration Systems task force). The
of all diagnostic messages, including
ASAP task force is composed of vehicle
emissions-related diagnostics (Part 73).
manufacturers, automation and test
The J1939/Part 21 specification presents equipment manufacturers, and ECU
information on the data link layer. It manufacturers. The mission of ASAP, as
describes the message format used by stated in the CCP standard “is to reach
J1939, detailing each bit in the extended mutual agreement and standardization in
format identifier (priority, source ID, etc.).
• automation, modularization and com-
And it describes the transport protocol
patibility of all equipment to do meas-
used on a J1939 network, covering the
urement, calibration and diagnosis,
packetization and reassembly of mes-
and
sages containing more than 8 bytes of
data, and the management of the virtual • manage the creation of a cost reason-
connections for transferring this large able and sensible tool supplier mar-
message. The Part 31 specification ket.”
defines the services used on a multi-seg-
In keeping with this mission statement,
ment vehicle network. These segments
CCP provides a CAN-based strategy for
may operate with different physical media,
the calibration of ECUs and the acquisition
protocols or data rates. So this specifica-
of data from ECUs. The ASAP task force
tion describes the use of repeaters,
describes a model involving three compo-
bridges, routers, and gateways to provide
nents: Measurement, Calibration, and Di-
the connections between segments.
agnostics.
The application layer defined by Part 71
The communication strategy described for
supports both point to point and broadcast
CCP is to utilize two CAN data frame
communications. Message frames con-
identifiers, one for the Command Receive For this specific implementation of CCP,
Object (CRO) and one for the Data we are using CAN message identifiers
Transmission Object (DTO). CCP uses reserved by the J1939 specification for
these two messages to operate in a mas- manufacturer proprietary functions. The
ter-slave style of network communications. 29-bit identifiers used are low priority and
The master device will be a measurement contain the destination address for this
system, calibration tool, or diagnostic tool, ECU.
and initiates communication with the slave
Selected Solution Implementation
device.
Following our ISO-9001 certified software
A CRO is the message sent from a master
development process, we decomposed
device (calibration tool in this case) to the
the requirements specification provided by
slave device (our ECU). The CRO mes-
our customer and produced a software
sage contains a command code, com-
requirements specification. In the review
mand counter, and any command-related
cycle for this software requirements speci-
parameters and data. Valid command
fication with our customer, the decision to
codes include writing calibrations, pro-
support only J1939 CAN communications
gramming the ECU, and requesting data.
was made.
A DTO is the message sent from the slave
device to the master device. The DTO will At the same time, we were conducting a

Figure 1 - Example CANape Screen

contain the response to a command, an trade study of commercially available

event message reporting internal status of development tools for the Motorola
the slave device, or the data supporting a MC68376, real-time operating systems,
previous data acquisition request. and calibration tools. A number of criteria
were considered when making our deci- placing the resultant data into data objects
sion, including usability, suitability to task, to be used by the application software.
follow-on technical support, and cost. When the application software needs to
After assessing the various options in the perform a hardware action, it calls the
area of calibration tools, CCP was appropriate function in the hardware
selected as the calibration methodology abstraction layer, identifying the appropri-
for this ECU development program. To ate data object. The hardware function
work with CCP, a commercially available then performs the action, such as writing
calibration tool was selected. At present to a register, or driving a serial port.
we are using CANape from Vector Infor- Within our communications subsystem,
matik, an example of the user interface is initializing the CAN controller, interacting
at Figure 1. However, by using CCP, the with the receive and transmit buffers, and
option to use a different PC-based cali- servicing all CAN controller interrupts, are
bration tool is possible. similarly handled in the hardware abstrac-
tion layer. CAN message information be-
Another goal desired by our customer was
comes a data object handled by the com-
to have the flexibility to move the applica-
munications subsystem. In the Motorola
tion software to a different microprocessor
MC68376 microcontroller the on-chip CAN
in the future. Such a move could result
controller is known as the TouCAN. This
from cost considerations during produc-
CAN controller supports 16 transmit or
tion, or application software growth after
receive buffers with three receive accep-
adding new features. This goal fits well
tance filters, and performs internal trans-
with our modular software development
mit arbitration to select the next message
approach. A simple block diagram de-
to attempt to transmit on the CAN bus.
picting the architecture of this application
is provided at Figure 2. One aspect of using CCP affected the
development of our application software.
In order to have data values available
from the ECU for monitoring, and to pro-
vide the calibration flexibility required dur-
ing development test, it was necessary to
include in the detailed design widespread
use of global variables in the software. To
calibrate the software and support the
data acquisition process, the CCP tool
needs to know the memory address of
these data values. So the tool reads the
software memory map, and links the cali-
bration and data acquisition objects to the
address location of the appropriate global
variable. Even though this action may be
contrary to good design and programming
practices, it is necessary in order to use
CCP to satisfy development system
requirements.
The J1939 communications subsystem
software was designed and coded at As-
To provide the capability to port the appli- cent Technologies, so as a result we could
cation to a new target processor, while easily incorporate CCP into the structure.
keeping software rework to a minimum, A portion of the high-level design is
we incorporated a hardware abstraction depicted in Figure 3. The path taken
layer into our design. This approach is when a CAN message is received is as
implemented as a series of functions follows: the CAN message data object is
which handle hardware specific actions, provided to the Manage_Data_Link_Layer
for example reading A/D registers, and by the TouCAN-specific receive message
 function. The Manage_Data_Link_Layer trouble codes (DTCs). And Manage_CCP
then performs the actions described in operates similar to Man-
J1939/Part 21, determining if the received age_J1939_Part73, responding to DTO
object is part of a multi-frame message, messages from the off-board tool, or
and reassembling the complete message directing a CRO to be transmitted in
if required. It then identifies where to send response to a previously scheduled data
the received Check_Msg_Queues
object. If it is a CCP mes- acquisition request. Manage_CCP, Man-
sage it is passed to Manage_CCP, if it is age_J1939_Part71, Man-
an application message it goes to Man- Download_Blocks
age_J1939_Part73 provide the transmit
age_J1939_Part71, or if it is a diagnostic message data object to Man-
N_Message_Status

Serial Data Manage_CCP

Serial Data Manage_Data

_Link_Layer
Serial Data

Serial_Sensor_Data
Manage_J1939
Serial Data _Part71

Application_Data

Manage_J1939
_Part73
Diagnostic_Data

Figure 3 - High-level Design Example

message it will be sent to Man- age_Data_Link_Layer. The process,

age_J1939_Part73. Manage_Data_Link_Layer, will determine
if the data object requires a multi-frame
Transmitting a message functions in the
message, preparing multiple CAN mes-
same fashion, only in reverse. For appli-
sage data frames if necessary. It will then
cation layer messages, the application
send the data object(s) to the transmit
software will call Manage_J1939_Part71
message function handling the TouCAN
to transmit the message. For diagnostic
transmit buffers.
messages, Manage_J1939_Part73 will
respond to diagnostic requests, or direct a While the J1939 software was designed
diagnostic message to be transmitted and coded in-house, we have benefited
announcing currently active diagnostic from the work at Vector Informatik with
CCP. They have generously made avail- FAX 01-734-668-2735
able to the public an example implemen- [email protected]
tation of CCP on their Web site. We have
incorporated this example software into
our J1939 communications subsystem,
modifying it to work with our operating
system and adding the functionality which
was absent, such as FLASH programming
support for the FLASH memory part used
in this ECU.
Conclusion
Use of the CAN Calibration Protocol has
provided a cost-effective solution for cali-
bration and measurement in this ECU
development program. An off-the-shelf
tool solution, offering more flexibility and
capability than likely with a proprietary
development, was identified and satisfies
all the needs of the development and test
engineers. Potential customers for this
ECU application have indicated their
interest in our use of CCP, and the
opportunities it offers within their devel-
opment and test environment. The
approach to calibration and measurement
utilized by CCP makes this suitable for
any ECU with CAN as a communication
link and requiring calibration, measure-
ment, or both.
References:
1. ASAP Standard – CAN Calibration
Protocol (CCP), version 2.1
2. SAE J1939 – Recommended Practice
for a Serial Control and Communica-
tions Vehicle Network
3. CCP Driver, Implementation in Elec-
tronic Control Units, Vector Informatik
GmbH (version 1.01)
Acknowledgements
Many thanks to my colleagues at Ascent
Technologies and Jacobs Vehicle Sys-
tems, and for the assistance provided by
the folks at Vector CANtech and Vector
Informatik.

Ascent Technologies, Inc.

525 Avis Drive, Suite 15
Ann Arbor, MI 48108 USA
Phone 01-734-668-4035