CAN Calibration Protocol

CAN Calibration Protocol (CCP)

MotoHawk now includes a CCP block set that enables handling a CAN Calibration Protocol (CCP) connection via CAN, and thus adds the capability for using CCP-based calibration tools such as ATI Vision, ETAS INCA, or DSPACE Caldesk.

What is CCP?

CCP is a standard intended to create a common interface to electronic control modules. MotoTune does not use this protocol, but ERI, which has similar concepts, although does not support Data Acquisitions (DAQs).

CCP does not currently support reprogramming of a module. This would still require use of MotoTune.

How CCP Works

Any MotoHawk model can utilize the integration with commercial calibration tools via use of MotoHawk [../MotoHawk_lib_Blocks/CCPCANProtocolHandler.html CCP CAN Protocol Handler] and related blocks. You may optionally configure parameters such as the CAN identifiers used, the storage space available for data acquisition, triggers, etc. With CCP block in place, the build process handles generating code which implements CCP and generates the module description file (ASAP2), which enables integration with commercial calibration tools.

Calibration tools typically import the module description file prior to being able to start communications with a controller. Since this import process can be cumbersome, MotoHawk now has the ability to directly generate a tool-specific project file via a command. After the build process, the project file is loaded by the calibration tool and communications with the module can be immediately started.

The CCP's ASAP2 file (similar in concept to the .dll file used by MotoTune) describes:

• Measurements – Variables that can be read (Probes)
• Characteristics – Variables that can be written (Cals)
• DAQ Triggers – Events that can automatically cause Measurement(s) to be sent to the tool without a request
• Engineering Conversions – Showing the signal in human form rather than fixed point (along with formatting and units)

CCP Data Lists

After the CCP session is properly established the master may request periodic transmission of selected data items. The data items of interest are each added to a particular transmission list, residing in the slave. The transmission list is assigned an event in the slave, called an Event Channel, on which the transmission is to occur. Event Channels can be defined as a fixed sampling rate or may be event driven (e.g. crank position). See [../MotoHawk_lib_Blocks/CCPCANProtocolHandler.html CCP CAN Protocol Handler] and [../MotoHawk_lib_Blocks/CCPDAQTriggers.html CCP CAN Protocol Triggers] for more information.

Note: Due to a current limitation of VISION, each available data list is only allowed to start on a particular Event Channel ID. The mapping of available data lists and available Event Channels is done sequentially in a one to one basis. As an example, suppose you chose to have only 4 data lists in your controller. This would mean that data list 0 could only be started at Event Channel 0, or FGND_RTI_PERIODIC. Data list 1 could only be started at FGND_2XRTI_PERIODIC, and so on. Again, this is only a limitation of VISION. The MotoHawk CCP Block supports starting any data list on any defined Event Channel.

CCP Security and the MotoHawk CCP Blockset

The MotoHawk CCP blockset includes blocks which support security capabilities for CCP communications with CCP-capable Calibration tools. These security capabilities are supported by some but not all calibration tools. For example, the tool must support the use of .dll files in configuring security parameters; these would include ATI VISION, INCA, and CANAPE applications.

The security blocks include:

• CCP Security Challenge Trigger (CAL)
• CCP Security Challenge Seed & Key (CAL)
• CCP Security Challenge Trigger (DAQ)
• CCP Security Challenge Seed & Key (DAQ)

Note there are CAL-designated blocks and DAQ-designated blocks. The respectively named CAL and DAQ blocks are functional equivalents and are actually interchangeable; these block names serve to inform that it may be useful to have security access requirements for calibration activity as separate and distinct from the security for data acquisition requests. For instance, one would typically use the (CAL) set to configure a security scheme for a calibration request, and/or set up security for a data acquisition request using the (DAQ) blocks. See Example Scenario below for more information on using the CCP security blocks.

Seed and Key Approach

The security method supported by the MotoHawk CCP blocks is the "seed and key" approach. This means that a "seed" value is supplied by the communication target to the requestor upon request for access to a particular CCP activity; the acquired seed value is then processed by the requestor through an algorithm to arrive at a "key" value. The key is then returned to the target; when the key value is supplied, if it is the expected value, the requested activity is allowed. If incorrect, the requested CCP action is denied.

A typical scenario would be to use CCP Security Challenge Seed & Key blocks along with the respective Security Challenge request. The MotoHawk CCP Slave library includes two example CCP security functions (Example_CCP_Security_Function, and Another Example_CCP_Security_Function).

Example Scenario:

In this scenario, the user would:

1. Place the CCP Security Challenge Trigger (CAL) block in the model; in the block parameters, enter an "Instance" name to exactly match the CCP Handler Instance Name. This enables the Security Challenge Request to be triggered for that CCP activity.
2. Tie the output (trigger) from the CCP Security Challenge Trigger to a trigger input for a "seed and key" function (example function expanded below).
   
   
3. In the example function above, when triggered, the security function first generates a seed value, in this case, the example function used combines the absolute time block value with the serial number in some way. The seed value output (2) is supplied to the CCP Security Challenge Seed & Key block (top-left input)
   
4. To this seed value, an algorithm is applied to generate another value, the "key." When this is complete, the key value is supplied to the output (3) is supplied to the CCP Security Challenge Seed & Key block (bottom-left input).
5. When the seed and key values are ready, the trigReply output (1) is supplied to the trigger input of the CCP Security Challenge Seed & Key block (top of block).

Create .dll File

The above scenario presumes the requesting calibration tool has the ability to take the supplied seed value from the target, and generate the required key value. In other words, the client would need to have the identical function to be able to compute the key value correctly. MotoHawk supports this requirement by including a folder with supporting files (look for the files in the installed MotoHawk application folder, in the path Blocks\CCPSlave\SecurityDLL) to help generate the security .dll file to be used by the calibration tool. Among the files is the README.txt file, which includes further instructions.