cpp协议

CCP v2.1　cpp协议CAN Calibration protocoVersion 21. 18-feb-9912.13 Write dAQ list entry..281214 Start/ Stop Data transmission……2912.15 Disconnect…3012.16 Set Session status.3112.17 Get session status321218 Build checksum3312.19c| ear Memory..,…,…3412.20 Program3512.21 Program 6 Bytes......3612.22 Move memory block.3712.23 Diagnostic Service.3812.24 Action service.ww3912.25 Test Availability.……,…,……,…,…,…,…,…,…,…,…,…,…,…,…,…,……,…4012.26 Start /Stop Synchronised Data transmission.....1227 Get currently active Calibration Page.………4212.28 Get implemented Version of CCP......4313 Error Handling..,…,,…,,,…,……,…4414 Example sequences.……4514.1 Session log-in........4514.2 Block Down load■■■■量■4514.3 Block UpLoad■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■口■■■■■■■■■■■D■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■4514.4 Calibration data initialization w4614.5 DAQ List Initialization...4614.6 Code update4615 Expected Performance Ratings■■■■■■■■■■■■■■■■■■■■■■■■■■目■■■■■■■■■■■aa■_■n■■a■■_■4716 Appendices.,………,………4816.1 Matrix of Error codes4816.2 Broadcast Techniques in Multi-point Applications.………………49Page iiCAN Calibration protocolVersion 21 . 18-feb-991 Introduction1.1 ASAPThe ASaP task force (Arbeitskreis zur Standardisierung von Applikationssystemen; Englishtranslation: Standardization of Application/Calibration Systems task force) has beenfounded by the companies Audi AG, BMW AG, Mercedes-Benz AG, Porsche AG andVolkswagen AG. European manufacturers of autmation, test and development systems forthe automotive industry as well as manufacturers of electronic control units have joined thistask forceThe world of automotive technology has grown into complex electronic systemconfigurations to meet the increased requirements in the area of legislated exhaust gaslimits, environmental pollution protection, security systems, driving performance and bodyequipment options. Some automotive manufacturers use in vehicle distributed controlsystems supported by networksTo develop this new generation of automotive electronics, new and high sophisticatedsoftware, calibration, measurement and diagnosis equipment has to be used. At this timealmost no standards exist in the area of software interfaces for such devices, eachcompany has its proprietary systems and interfaces to support the development of thesehigh end configurationsTherefore, the mission of asaP is to reach mutual agreement and standardization inautomation, modularisation and compatibility of all equipment to do measurementcalibration and diagnosis, andmanage the creation of a cost reasonable and sensible tool supplier market1.2 CAN Calibration Protocol (CCP)The Controller Area Network CAn is a joint development of robert Bosch gmbh and IntelCorporation Can is used in many high-end automotive control systems like enginemanagement as well as in industrial control systems. Controller chips for CAN are availablefrom various semiconductor manufacturersThe CAN Calibration Protocol is part of the ASAP standards. It was developed andintroduced by Ingenieurburo Helmut Kleinknecht, a manufacturer of calibration systems,and is used in several applications in the automotive industry. The CCP was taken over bythe ASAP working group and enhanced with optional functionsCAN Calibration protocolVersion 21. 18-feb-992 Scope and field of applicationThis document specifies the CAN Calibration Protocol CCP, as defined by the work groupwithin the asap task forceThe CCP defines the communication of controllers with a master device using the CAN2.0B(11-bit and 29-bit identifier), which includes 2.0A(11-bit identifier) for1. data acquisition from the controllers,2. memory transfers to and control functions in the controllers for calibrationProviding these functions the CCP may be used in the areas ofdevelopment of electronic control units(ECU)systems for functional and environmental tests of an ECUtest systems and test stands for the controlled devices (combustion enginesgearboxes, suspension systems, climatic control systems, body systems, anti-lockingsystemson-board test and measurement systems of pre-series vehicles, andany non-automotive application of CAN-based distributed electronic control systems3 Related documentsSpecifications and data sheets from Intel Corporation82527 Serial Communications Controller Datasheet(Intel #272250)82527 Serial Communications Controller Architectural Overview(Intel #272410)Introduction to the Controller Area Network(CAN) Protocol(Intel #270962)4 Revision historyRevision DateItem(s)changedNote1.030-Sep-1992Initial release fromIngenieurburo HelmutKleinknecht1.01b07-Dec-1995 Working draft, with the following optional ASAP work groupcommands addedEXCHANGE IDGET SEEDUNLOCKGET DAQ SIZESET DAQ PTRWRITE DAQACTION SERVICEand the return /error codesSession status requesCold start requestCal. data init requestDAQ list init requestcode update requestaccess lockedPage 2CAN Calibration protocolVersion 21. 18-feb-99Revision DateItem (s)changedNote1.0226-Apr-1996Explanation of daQ listsDraft for discussion inExtended description incl. examples ASAP work groupMOVE command addedPROGRAM command added2.014-June-1996-Command STORE CYCLE removed, Result of aSAP workCommand dnload 6 addedgroup meetingCommand Program 6 addedDocument status.Block size in build chKsumReleaseMemory size in CLEAR MEMORY,Return information get daQ sizeTimeout for build chKsumProp. 2.0116-March- 1998 commands modifiedDraft for discussion inEXCHANGE IDASAP work groupGET SEEDDocument statusSTART STOP. Evt chnl PrescalerDraftBUILD CHECKSUM sizecommands addedTESTGET CCP VERSIONGET ACT CAL PAGESTART STOP ALLitem removedWCo WakeUp/ Connect objectDraft 2.123-June-1998 Chapter Version mechanismaddedResult of asap workChapter Version compatibilityadded group meetingDOWNLOAD6 classed optionalDocument statusSHORTUP classed optionalDrafAppendix Matrix of Error codesadded2.118-Feb All changes Prop. 2.01 and Draft 2.1Document statusactiveRelease /publicPage 3CAN Calibration protocolVersion 21 . 18-feb-995 Definitions and AbbreviationsCANController Area Network: communications protocol (in ISo/OSI model level 1+ 2)developed and maintained by Robert Bosch GmbH. The protocol is designed tomanage multiplexed communications between multiple CPUs. It is control informationoriented, uses non -destructive bit-wise arbitration to decide which node owns thebus, and has a message priority scheme based on the value of the messagedentifier transmitted with each messageCCPCAN Calibration Protocol: Developed by Ingenieurburo Helmut Kleinknecht andadopted by the asaP task force as a standard protocol for data acquisition andcalibrationCROCommand receive object: message sent from the master device to the slavedevice(s)CRMCommand Return Message: one type of message sent from the slave device to themaster device containing command /error code and command counterDAQData Acquisition: definition of a procedure and messages sent from the slave deviceto the master device for fast data acquisition from an Ecu sentDTOData Transmission Object message sent from the slave device to the master device(Command Return Message or Event Message or Data Acquisition MessageECUElectronic Control Unit: an electronical device with a central processing unitperforming programmed functions with its peripheral circuitryMessage objectA message transfered on the CAN, which is sent from a transmitting ECu to anreceiving /listening ECU. The coding of the data contained in the message isknown" by the receiving ECUs. A message object's data can be o to 8 bytesMessage FrameMessage frame is a synonymous name for message object in the recent literatureon canMaster and slave devicesA set of controllers connected via CAn exchanges Message Objects. An additionalexterna controller connected to the network which communicates with one or moreof these controllers and issues commands to them here is called a master device(host). The controllers in the existing network receiving commands are called slavedevicesODTObject Descriptor Table: list of elements(variables), used for organisation of dataacquisitionPage 4CAN Calibration protocolVersion 21. 18-feb-996 Protocol definitionThe Can Communication Protocol used for Calibration and data acquisition is a masterslave type communication. A master device is connected with one or more slave devices onthe candeviceCANSlaveSlavedevicedevicedeviceConfiguration of Master and slave devicesThe master device(host) is a calibration tool or a diagnostic monitoring tool or ameasurement system initiating the data transfer on the can by sending commands to theslave devices. The CCP implementation supports commands for generic control withprimitive memory transfers and for data acquisition. These two parts(function sets)of thecommunication protocol are independant and may run asynchroneously, depending on theimplementation in the slave controller. It is also possible that messages of both parts aretransmitted in nested order6.1 Generic Control commandsThe commands are used to carry out functions with and in the slave device. For thispurpose a continuous logical connection is established between the master device and anyother station on CAN (slave device). This logical connection is valid until another station isselected or the current station is explicitly disconnected via commandAfter the initializing logical connection has been made, data transfers from the masterdevice to the slave device and from the slave device to the master device are controlled bythe master deviceAll commands from the master device have to be prompted by the selected slave devicewith a handshake message(command return code or error code)6.2 Data Acquisition CommandsThese protocol commands are used for continuous data acquisition from a slave deviceAny CAn node may periodically transmit internal data corresponding to a list that has beenconfigured by control commands from the master device Data transmission is initiated bythe master device and executed by the slave device and may be dependant on a fixedsampling rate and /or may be event driven(e.g. crank positionPage 5CAN Calibration protocolVersion 21 . 18-feb-997 Message objects7.1 Organisation of Message objectsAccording to the definition of the can all messages and data to be transfered are packedinto "message objects", containing up to 8 byte of data. A message object is sent from onecan node to other can nodThe CCP requires at least two message objects, one for each direction1)Command Receive object: CRO2)Data Transmission ObjectDTOThe Cro is used for reception of command codes and related parameters to carry outinternal functions or memory transfers between the logically connected can devices. Thereception of a command has to be prompted with a handshake message using the DataTransmission Object Dto (see below), and in this case a dto is called a CommandReturn Message. The return code of this dto message is used to determine whether thecorresponding command has been successfully completed or notCCP Master (Calibration tool)CCP driverCANCRODTODTOCommandDAQprocessorprocessorCCP Slave (ECU)Functional Diagram Communication flow between CCP master and slave devicesThe assignment of message identifiers to the above described objects is defined in theslave device description file (e.g. the ASAP2 format description file), which is used toconfigure the master device. It is recommended that the bus priority of the message objectsis carefully determined in order to avoid injury to other real-time communication on the busAlso, the Cro should obtain higher priority than the dtoFor all data transfered by the ccp no byte order for the protocol itself is defined. Becausethe data organisation depends on the eCus cpu, the byte ordering is defined in the slavedevice description file. The only exceptions are the station addresses in the TEST,CONNECT and disConnEcT commandsPage 6CAN Calibration protocolVersion 21 . 18-feb-997.2 Description of Message objects7. 2. 1 Command Receive Object CROA Command Receive Object CRo is sent from the master device to one of the slavedevices. The slave device answers with a Data T ransmission Object DTO containing aCommand Return Message CRMStructure of objectypeRx onlySize8 bytes message fieldPurposeReception of commands in the slave deviceParameters in message fieldPositionTypeDescription0bytecommand code cmdbytecommand counter ctrbytescommand related parameter and data areabv0CMDCTRParameter and data fieldThe data lenght code of the Cro must always be 8. Unused data bytes, marked as don 'tcare, in the command descriptions, may have arbitrary values7.2.2 Data Transmission Object DTOThe dto has to carry all outgoing slave device messages and data as data packets. Thfirst byte of a data packet(i.e. first byte of the dtOs data field)is used as the Packet IDThe dto is aCommand Return Message crm, if the dto is sent as an answer to a crofrom the master deviceEvent Message, if the dto reports internal slave status changes in order toinvoke error recovery or other services. Details are explained in the chapter ErrorHandlingData Acquisition Message, if the Packet ID points to a corresponding objectDescriptor Table (ODT), that describes which data acquisition elements (i.evariables) are contained in the remaining 7 data bytes of the packet. The Odtsare initialized and modified via protocol commands(see chapter Description ofCommands)Structure of objectypeTx(and Remote Tx Request reception)Size8 bytes message fieldPurposeCommand return Message cRm orEvent Message orData Acquisition MessagePage 7