Compact Can Integration Overview

8/2/2019 Compact Can Integration Overview

http://slidepdf.com/reader/full/compact-can-integration-overview 1/21

Compact CAN Integration Overview

Version 28.3 Proprietary and Confidential Last Update:

27/Apr/09 of 21 Copyright © 2000-2009 Cellocator


Version: 28.3

Updated: 27/Apr/09

CONFIDENTIAL

This document contains proprietary information that is the sole property of Pointer Telocation Ltd. The document is submitted to the recipient for his use only. By receiving this document, therecipient undertakes not to duplicate or to disclose, in part or the whole, any of the informationcontained herein; to any third party; without a-priory written permission from Pointer TelocationLtd.






TABLE OF CONTENTS

1 TRACEABILITY TABLE .......................................................................................................... 3 2 INTRODUCTION ..................................................................................................................... 4

2.1 About this Document ........................................................................................................ 4 2.2 General ............................................................................................................................ 4

2.2.1 High level Features ....................................................................................................... 4 2.2.2 Device Architecture ...................................................................................................... 4

2.3 Used Abbreviations .......................................................................................................... 5 2.4 Related Documents .......................................................................................................... 5

3 GENERAL DESCRIPTION ...................................................................................................... 6 3.1 CAN General Overview .................................................................................................... 6

3.1.1 Specification Versions .................................................................................................. 6 3.2 ISO11898 ......................................................................................................................... 6 3.3 J1939/FMS ....................................................................................................................... 7

4 INTEGRATION PRINCIPLES .................................................................................................. 9 4.1 The CAN Harvester .......................................................................................................... 9 4.2 The Sensors Array ......................................................................................................... 10 4.3 The Sensor Triggers ....................................................................................................... 10 4.4 CAN Data Delivery ......................................................................................................... 10

4.4.1 Can Status Interrogation ............................................................................................. 10 4.4.2 An active CAN Message ............................................................................................. 11

4.5 Available Trigger Types .................................................................................................. 13 4.5.1 Threshold Trigger ....................................................................................................... 13 4.5.2 Delta Trigger ............................................................................................................... 13 4.5.3 Periodic Trigger .......................................................................................................... 13 4.5.4 Complex Trigger ......................................................................................................... 13

4.6 Reporting CAN Speed and Odometer in Position Messages (Msg. Type 0) ................... 15 5 CONFIGURATION ................................................................................................................. 16

5.1 Data on CAN (J1939 example) ....................................................................................... 16 5.2 Selecting Sensors .......................................................................................................... 17 5.3 Setting Templates for a Trigger ...................................................................................... 17 5.4 Assigning Simple Triggers .............................................................................................. 19 5.5 Assigning Complex Triggers ........................................................................................... 20






1 Traceability TableVersion Date Description

28.1 4/02/09 Original version

28.2 8/02/09 The name of the document modified

Device architecture chart added

Minor modifications and fixes after review

28.3 27/4/09 Minor description mistakes are fixed

Complex trigger generation description updated






2 Introduction

2.1 About this Document

This document is intended to provide a clear understanding of the integration of the Cellocator unitwith the vehicle‟s CAN bus, its operational logic, CAN bus event reporting options, and accompanying debugging and configuration tools.

2.2 General

2.2.1 High level Features

Using the provided interface the customer will be able:

To monitor up to 25 parameters, reported over the vehicle‟s CAN bus from the CCC, bypolling or periodical auto-updates.

To generate active messages to the CCC carrying CAN data, triggered by pre-definedlogical conditions.

2.2.2 Device Architecture

The following illustration provides an overview of the Cellocator device.






2.3 Used Abbreviations

Abbreviation Definition

ACK Acknowledge

CAG Controller Area Network

CCC Command and Control Center

PDU Protocol Description Unit (Common name for data SMS)

SMS Short Message Service (GSM)

DB Database

OTA Over the air

2.4 Related Documents

No. Document Name Version Date Remark

1 SAE j 1939-71 December 2004 Or newer

2 FMS document Ver 01.00 1.00 January 2, 2007

3 FW28 Release Notes 1 January 14, 209

4 Appendix - ModularMessage type 9 v28_1

February 2, 2009






3 General Description

3.1 CAN General Overview

The Controller Area Network (CAN) was created by Robert Bosch in Germany in March, 1985. TheBosch Company designed it to replace automotive wiring.

3.1.1 Specification Versions

In early versions of the specification (version 1.2, Part A), CAN messages contained an 11 bitidentifier providing the capability to address 2047 identifiers. In 1992, CAN specification 2.0, (Part B), extended the identifier size to 29 bits providing up to 56million unique identifiers. The goal was to make automobiles more reliable, safe and fuel-efficientwhile decreasing wiring harness weight and complexity.

Since its inception, the CAN protocol has gained widespread popularity in industrial automation andautomotive/truck applications. 3.2 ISO11898

The Cellocator unit is compliant with the ISO1189 standard, as described below.

The CAN protocol defines the Data Link Layer and part of the Physical Layer in the OSI model.

The CAN bus is a balanced (differential) 2-wire interface running over either a shielded twisted pair(STP), un-shielded twisted pair (UTP), or a ribbon cable. A transceiver is able to drive a 40m bus at

Cellocator Unit






1 Mb/s. A longer bus length can be achieved by slowing the data rate. The specification also

requires 120 (nominal) terminating resistors at each end of the bus.

The CAN bus specifies two logical states: recessive (logic „1‟) and dominant (logic „0‟), and ISO-11898 defines a differential voltage to represent recessive and dominant states (or bits) as shownin the following figure:

A Cellocator CAN unit has two pins on its main interface connector compatible to ISO-11898:CANH (pin 11/20) and CANL (pin 5/20).

The unit is adapted by default to a 250kbs bus, but can be adapted to other bus speeds uponcustomer request (requires firmware upgrade).

3.3 J1939/FMS

The J1939 protocol is one of the most popular CAN protocols, widely used by European carmanufacturers and, since 2008, mandatory on each trucks manufactured in the United States aswell. It defines an Application Layer for vehicle use (see 7-layer model above.) . This layer containsmanagement functions and generally useful mechanisms to support applications, but none of thedefined functions and mechanisms is mandatory.






The J1939 protocol was developed by the SAE (Society of Automotive Engineers) in order to

provide a standard architecture by which multiple electronic systems on a vehicle cancommunicate. It was developed by the Truck and Bus Control and Communications NetworkSubcommittee of the Truck and Bus Electrical and Electronics Committee, but its use is not limitedto truck and bus applications.

The Cellocator configuration tools allow easy integration with any J1939 compliant bus.

The FMS (Fleet Management System) protocol, adapted by major European track manufacturers,is based on J1939 and defines a small subset of J1939 packets (PGNs) which are mandatorilysupported by vehicles that have been declared as FMS compatible.

The Cellocator configuration tools allow plug-n-play integration with any FMS compliant vehicle, theconfiguration in this case is a based upon a selection of the required parameters from drop-downmenus.






4 Integration PrinciplesThe CAN bus extensions in the Cellocator unit are designed with flexibility in mind, and do notrelate to the higher-level protocols in use above the CAN interface.

The unit, by default, takes active part in the error management protocol in the CAN data layer. Itgenerates passive and active errors upon detecting erroneous conditions. However, the unit doesnot take any part in higher-level communications.

This approach provides several benefits:

Lack of interaction with the higher layer assures the unit will not cause any disturbance orinterference with the operation of other systems in the vehicle.

Not relating to specific communications on any specific higher layer assures that the unithas access to a broad range of communication protocols, with the ability to adapt to newerprotocols in the future.

The Compact CAN unit is installed as one of the nodes on the bus. It is thus exposed to the entireCAN bus traffic of the vehicle while allowing selection and processing only of the relevantparameters.

.

Cellocator CAN processing is based on the following three main modules:

4.1 The CAN Harvester The CAN Harvester is an array of filters. Each packet (frame) sent over the bus is examined by thisfilter. The filter's condition, which is actually the XOR mask, defines which CAN frames will passthrough the filter. A received CAN frame can match more than one filter. In this case it passesthrough all of the matching filters. If it matches none of the filters, the frame is discarded withoutany further processing.






4.2 The Sensors Array

The sensors array is a storage space for information extracted by the CAN Harvester module. Eachsensor is linked with one of the filtered parameters in the array. Every time, a containing frame isfiltered from the CAN traffic, the value in the corresponding sensor is updated with the new valuereceived from the CAN.

4.3 The Sensor Triggers

The sensor trigger defines the logical condition for generating messages to the CCC. This conditionis checked every time that the content of sensor is updated with newly extracted data from the bus.

More than one condition (trigger) can be assigned to a single sensor. A single trigger can also beassigned to two sensors, as described below.

There are two versions of Compact Can units:

Capable of managing 8 CAN sensors.

Capable of managing 25 CAN sensors.

The 8 sensors version supports creation of up to 8 triggers, the 25 sensors version supports up to24 triggers.

Note, that the 25 sensors version consumes twice more power because the frequency of its internalcontroller is 2.5 times faster than the frequency of controller in the 8 sensors version.

4.4 CAN Data Delivery

The CAN data is delivered by the Compact CAN unit to the CCC in two cases:

The CCC interrogates the unit for the content of the CAN sensors.

The unit generates an active CAN message as a result of violation of one of the logicalconditions (triggers) assigned to the selected CAN sensors.

4.4.1 Can Status Interrogation

In this case, the unit delivers content of all CAN sensors in a single type 9 sub data type 2 message(refer to Appendix – Modular Message type 9 v28_1). The sensors in this message are notindexed, and are allocated in the same order as they are programmed in the EEPROM:

Cellocatorheader

Sensor 1 Sensor 2 … Sensor X CellocatorCheck Sum

Each sensor utilizes 6 bytes reserved for data extracted from CAN and one byte indicating effectivebit length; the infrastructure of an OTA type 9 message allows requesting the GPS stamp to be sentas a part of the same packet.






Cellocatorheader

Sensor 1 Sensor 2 … Sensor X GPSStamp

CellocatorCheckSum

Note, that the 25 sensor version of the Compact CAN does not allow for SMS interrogation becausethe reply would be much longer than a PDU SMS can carry (25*6byes per sensor=150 characters,while the PDU SMS can only handle 140 characters).

4.4.2 An active CAN Message

In this case, the unit generates an active message upon violation of one of the conditions, definedin a trigger. An active trigger can be generated in three ways:

As a real-time message of type 9, sub data type 2. It appears as "RealTime CAN" inCellocator tools. This type of message is similar to that discussed in the previousparagraph. It is not recommended because:

o It does not clarify which of the sensors has violated the condition.

o It is not equipped with a GPS stamp.

o It is not logged and not repeated, which means that the message will be lost if there isno coverage at the moment of generation.

o In the 25-sensorversion, it cannot be delivered by SMS.

As a real-time message of type 9, sub data type 3 . It appears as "Specific Data" in

Cellocator tools. This is another method of CAN event generation, with an improvedmessage format. The generated event contains an index of the sensor, which caused atrigger, i.e. the content of this sensor and, optionally, content of other indexed sensors andthe GPS stamp. This message format allows creation of four content patterns and themessages will be generated in accordance to one of them.For example : the first pattern will only include the triggered sensor itself with the GPSstamp. The second pattern will include the triggered sensor, the third sensor and the fourthsensor, as well as the GPS stamp.

Pattern 1

CellocatorHeader

Index oftriggered

sensor

Spare Number ofincluded sensors :

1

Triggeredsensor content

(with index)

GPSStamp

CellocatorCheck Sum

Pattern 2

CellocatorHeader

Index oftriggeredsensor

Spare Numberofincludedsensors: 3

Triggeredsensorcontent

Contentof sensor3(indexed)

Contentof sensor4(indexed)

GPSStamp(optional)

CellocatoCheckSum






Once the patterns are set, it is possible to assign it to any trigger.

There is no limit to the number of sensors delivered with the pattern, so it is possible to include allthe sensors in the pattern and to add a GPS stamp to it. In this way, upon trigger, the CCC receivesa message with all the defined sensors, a number (or two numbers) of triggered sensors and theGPS stamp.

Note, that the message is still generated in a real time format. It means, that the message is notlogged and not repeated, and therefore will be lost if there is no coverage at the moment ofgeneration.

As a logged message of type 9, sub data type 3. It appears as "Specific Data - Logged"in Cellocator tools. This type is very similar to the one described above, with two majordifferences:

o The message will be logged and will require Generic ACK from CCC (message type 4,(refer to Wireless Protocol)) in order to be deleted from the memory. If the ACKmessage is not received, it will be resent. The message utilizes the same amount ofmemory as a plain position event (message type 0), physically allocated in the samememory slot and threaded by the unit in the same way as message type 0. Thereforethe unit can store the same number of CAN events – namely 2256.

o Although the message is constructed according to a pre-set pattern, the pattern'sstructure has constant length and is limited to the following structure:

CellocatorHeader

Index oftriggeredsensor

Spare Numberofincludedsensors:

1-3

Contentoftriggeredsensor

withindex

Contentofadditional

sensor(a) withindex orzeros

Contentofadditional

sensor(b) withindex orzeros

GPSStamp

CellocCheckSum

Note : The Complex Trigger (both logged and real-time, see description below in section 4.5) has adedicated hardcoded pattern: both triggered sensors, an additional sensor and the GPS stamp.

The only variable item in this pattern is an index of the additional sensor. Each complex trigger (outof 8) can be assigned with different additional sensor. If the message carries less than the allowedthree sensors the unused bytes are sent as zeros.

Complex Trigger (logged and real time) pattern:

CellocatorHeader

Index oftriggeredsensor(a)

Index oftriggeredsensor (b)

Number ofincludedsensors: 3

Contentoftriggeredsensor (a)with index

Contentoftriggeredsensor (b)with index

Content ofanadditionalsensorwith index

CellocatorCheckSum






4.5 Available Trigger Types

There are two general types of triggers:

Single Triggers

Complex triggers

Simple triggers are of the following types:

4.5.1 Threshold Trigger

This trigger type is used in order to detect that sensor‟s value has exceeded the Maximum orMinimum level. It is possible to choose between single update per exceeding period and update pereach exceeding update. The easiest way to illustrate those options is to provide example:

If we are trying to detect overspending, we will assign Threshold trigger to a sensor, containing speed of the vehicle. This will be a Maximum threshold type (as we look for the value higher then ... km/h), of the "single update per exceeding period" (because the Speed is reported on bus 10 times a second and generating an event on each exceeding update is absolutely useless).

4.5.2 Delta Trigger

This trigger type is used in order to determine if a sensor‟s value has exceeded the maximumallowed value between two consecutive updates of the specific sensor.

4.5.3 Periodic Trigger

This trigger type is used as a periodical update, but it is not actually time that is counted. Thetrigger occurs after a preprogrammed number of specific sensor updates. Since the number ofupdates is normally defined in the protocol, the number of updates defines a period.

4.5.4 Complex Trigger

A Complex Trigger can be occur upon concurrent violation of two simple triggers for a predefinedtime period, or violation of a single trigger for at least a predefined time period.






A complex trigger can be defined based upon a subset of the mentioned parameters e.g. one

sensor and a time filter, or concurrent activation of two Simple Triggers. In other words it is possibleto select two single triggers (assigned to the same sensor or different sensors), and the timeinterval while they both are concurrently violated before the “Complex Trigger” message isgenerated.

Notes:

A complex trigger will always cause a generation of a message, containing values of bothsensors of the complex trigger, the third sensor (additional one, configurable) and the GPS(see description in Can Data Delivery Options section above in this document, 4.4.2).

The maximum number of complex triggers is 8 (in both 8 and 25 sensors version).

The time counter of each trigger is up to 255 seconds.

Each simple trigger can be set as either part of complex trigger or simple trigger. The same triggercannot be defined simultaneously as part of both a complex trigger and a simple trigger.

The same single trigger can be used for more than one complex trigger (although it is notsupported yet by Cellocator tools).

The complex trigger input can only be constructed from triggers of the "Threshold" type, with asingle trigger per exceeding period.






4.6 Reporting CAN Speed and Odometer in PositionMessages (Msg. Type 0)

The feature is supported by a Compact CAN and allows replacing the GPS estimated speed andodometer values in message type 0 in the Wireless Protocol, by the more accurate values receivedfrom vehicle's CAN bus. Note that this feature will only be supported with J1939 compliantvehicles.

In order to activate this feature, the CAN sensor 1 should be configured to capture the Odometerand CAN sensor 2 should be configured to capture the Speed from the CAN bus. The CompactCAN normalizes values received from the CAN bus into a common format described in theCellocator Wireless Protocol:

GPS Format of both fields:

According to CellocatorWireless CommunicationProtocol

CAN (According to FMS-Standard Interface Description)

Odometer 3 bytes, in “distance baseunits” programmed inEEPROM

4 bytes, in 5m resolution

Speed 4 bytes, in 10-2 m/sec

resolution (centimeters/sec).

2 bytes , in 1/256 km/h resolution

In order to notify the CCC that the Speed and/or Odometer fields of the message monitor CANoriginated data, the unit sets corresponding bits in the Communication Control byte of the message(refer to Wireless Protocol for more details about data source monitoring).






5 Configuration

5.1 Data on CAN (J1939 example)

Before describing the configuration process it is important to understand what the data on the buslooks like. The following is a short example of a J1929 log, recorded from the Scania track.

The right column contains the header of the message (PGN, the 29 bits identifier), length of data(always 8 bytes), the data itself and the timestamp.

According to the FMS document, the speed is recorded in a frame structured from PGN 0xFEF1

The speed is allocated in bytes 2 and 3 (16 bits value, starting from bit 8). In our example the value

is 0x00 00, which means 0 km/h.






5.2 Selecting Sensors

Cellocator's configuration tool, integrated in both wire and wireless communication softwarepackets, allows for the easy creation of a new sensor or selection of the pre-set one from the dropdown list. A Selected sensor is automatically assigned with an index. If the required sensor is not inthe list, it is easy to create a new one by choosing the name, the PGN according to the J1939document, the length of data and other attributes of a required sensor.

5.3 Setting Templates for a Trigger

Once all the required sensors are selected, templates for future triggers are generatred. This isdone by selecting optional sensors and, optionally, the GPS module. The example below shows atemplate, containing additional Speed and Odometer sensors, as well as the GPS packet.






5.4 Assigning Simple Triggers

The Simple Trigger configuration form provides:

Selection of the sensor to be applied (in our example sensor 1, Speed).

Input processing type (simple trigger type, as described above, in our example – ThresholdTriggering, Maximum 100 km/h, Single trigger per exceeding update.

A trigger output. Selection of "Realtime CAN message" will cause the generation of the"real-time message of type 9, sub data type 2". Selection of "Specific data" option willgenerate the "real-time message of type 9, sub data type 3". Selection of Specific data – logged option will generate the "logged message of type 9, sub data type 3".

If one of the Specific Data types is selected, the operator is offered a selection of patterns

for event generation:






5.5 Assigning Complex Triggers

The complex trigger interface facilitates setting two simple sensors and the time of concurrentviolation to generate a trigger. Since the template of Logged complex trigger is constant, the formlets the operator assig one additional sensor:

The example demonstrates a complex trigger, setting Speed and Engine RPM simultaneousviolation for 15 seconds.

The following example presents a screenshot of the configured complex trigger screen.

Compact Can Integration Overview

Documents

Transcript of Compact Can Integration Overview