Can Canopen

CAN and CANopen: Interconnecting Embedded Devices to enable the Internet of Things
Stephen Olsen, Product Line Manager, Operating System Platforms, Wind River Lalita Godbole, Founder, Octrian LLC
2013 Wind River and Octrian All Rights Reserved
Session Outline
Introduction Design of distributed applications CAN protocol technical overview SocketCAN interface CAN for the Internet of Things CANopen

2
What is CAN?
Controller Area Network Originated in automotive industry as communications bus in automobiles Used in safety-critical applications Defines how a message is delivered Does not define the meaning of the message

3
CAN Applications
Proprietary protocols
Example: ECU to ECU communication in a vehicle
Open protocols based on CAN

IDB-C (automotive) J1939 (automotive) DeviceNet (industrial) CANOpen (industrial)

4
Distributed Application Design

Multiple devices required to perform the task:
Robot arm Welding gun and temperature sensor Video camera Monitoring system Conveyor belt Temperature sensors Safety proximity sensors Etc.
Monitoring system
Camera
Welding gun Robot arm

Devices
Each device in the distributed application has its own processor or programmable logic device To make the application work, devices must be able to send messages to each other
Monitoring system
Camera
Bus Architecture
Bus architecture connects all devices to one communication line Protocol needed to handle ownership of bus
Monitoring system
Camera
Bus
Implementation Step 1: Determine messages

Determine what needs to be communicated between devices
Monitoring system
Temperature reading Weld command
Camera
Proximity reading
Position command
Welding gun
Robot arm
Implementation Step 2: Define messages

Define all the different messages that need to be communicated Sort them in order of priority
Weld commands Position commands Proximity values Temperature readings
Implementation Step 3: Sending messages

Program each node to send out appropriate messages onto the bus as needed
Monitoring system
Camera

Implementation Step 4: Receiving messages

Program each node to accept messages that concern them and to react to those messages
Monitoring system
Camera

Implementation Step 5: Error conditions

Program each node to act on error conditions Example: Broken physical connection in network automatically turns off welding gun and freezes Camera robot arm
Monitoring system Sound alarm
Off Freeze Welding gun Robot arm

Bus Protocol Criteria

High priority messages must not be delayed by low priority messages Devices must be able to detect when they are disconnected from the network Glitches in physical layer must not result in a miscommunication of message
Warning! I hear: Move backward Disturbance
I say: Move forward
CAN Physical Layer
Media Layer
Twisted pair carries the signal
15
Terminating Resistors
Both ends of the CAN cable is terminated by 120 across the twisted pair 120
120
16
Physical Link Layer
110010110..
Differential Voltages are interpreted as bits of data
Baud Rates
Baud rate = bits per second Typically 100kb/s to 1Mkb/s Faster baud rates need shorter cable lengths
CAN Flexible Data-Rate (CAN FD)

Still uses CAN bus arbitration method
Arbitration process
Receiver ACKs CRC delimiter
Occupied Bus
Data takes up the entire bus No other data can be sent until current transmission is finished All nodes receive the same data
Yes
Yes Yes
Messages
Messages are identified by their functionality Functionality is assigned by distributed application (user of CAN protocol) Brake commands
Diagnostic information
Speed control messages Temperature readings

Temperature requests
Message Filtering
All nodes receive the same message Upon receiving the message, each node decides whether or not it needs that type of message
I need speed control messages, brake commands, and temperature readings
I need speed control messages and diagnostic information
Message Priority
All messages are ordered by priority Priority is determined by the identifier Message identifiers are assigned according to priority Smaller identifiers have higher priority Important for distributed application to assign priorities correctly and avoid using the same message identifier
0x101 Higher priority
Brake commands
0x220
Speed control messages Temperature readings
0x240
0x250
Temperature requests
0x330
Diagnostic information
Arbitration
When two nodes start sending different messages at exact same time, the higher priority message always takes precedence Sender of low priority message backs off and retries when the bus is idle
High priority message is on network. Try again when bus is idle.
No Yes Accept
High priority
Yes Yes Ignore
Message Frames
1 bit: Start signal
0 8 bytes: Data 16 bits: Checksum 2 bits: Acknowledge
11 or 29 bits: Message identifier
6 bits: Number of data bytes (0 8)
Error Detection
Nodes that detect errors send out an error signal immediately Sender detects error signal and aborts message immediately Sender retries as soon as bus is idle
Sending message
Error signal detected Resending Sending error signal
Sender
Any node
Error detected
Time
Error Types (1 of 2)
Frame error
Message received violates CAN message structure
# Checksum error
Checksum does not match rest of CAN message
ACK error
?
Sender node receives no ACK signal
Error Types (2 of 2)
Bus monitoring error
0011011010100011 0011011010100010
mismatch
Sender, monitoring the bus as it is sending, receives a bit different from the one it sent
Correct: 6th bit after 5 consecutive matching bits is stuffed Bit-stuffing error 000001 111110
Error: 6th consecutive matching bit violates bit-stuffing rule 000000 111111
Signal received violates bit-stuffing rule
CAN Properties
Protection against intermittent bus errors Ensures timely delivery of high priority messages Allows multi-casting: All nodes listen to same message Notification of broken network Fault confinement
Controller Functionality
CAN controllers take care of
Sending and receiving messages Message arbitration Message filtering ACK signalling Error-checking Resending of unsent messages Calculating checksum Bit-stuffing Bus-monitoring during send action Keeping track of error count Bus-off when error limit is exceeded
000001 111110
Accept Ignore
SocketCAN
Standard Linux CAN drivers use SocketCAN Uses Sockets with a different protocol family
AF_CAN and not AF_NET
Use industry standard socket interface

socket(PF_CAN, SOCK_RAW, CAN_RAW); write(s, &frame, sizeof(struct can_frame));
Provide various socket level filters for CAN messages.

CAN_RAW_FILTER, CAN_RAW_ERR_FILTER,

31
CAN for the Internet of Things
An Interconnected World
Internet of Things Machines talking to Machines What brings smarts within the Machine ?
Remote Control
An Interconnected World
What brings smarts within the Machine ?
actuators
actuators
HMI
sensors
Monitor
sensors
An Internet of things within a machine

actuators
actuators
HMI
sensors
Monitor
sensors
CAN Bus
Controller Area Network
Why CANopen ?
Standard Object Oriented Design Quick and Easy Deployment Plug and Play Ease of application configuration Ease of connectivity Interoperability of devices and tools
Typical Applications
Medical systems Vehicle automation Vending machines Rail vehicles Power generation Maritime electronics Robotics Defense
Robot Arm
Automotive
Medical Systems
CANopen Protocol
CANopen Deep Dive

Application Session Session Transportation Network Data Link Physical CAN Controller (CAN 2.0 A) CAN Transceiver (ISO 11898) CANopen
CANopen: Basic Concepts

Object Dictionary CAN Message Specification (CMS)
Defines contents and types of CMS objects via DS 301 Communication Profile
Network management Layer management Distributor Device and Application Profiles Electronic Data Sheet Device Configuration File
Object Dictionary
Every device must implement an object dictionary
State Machine
Communication object (NMT, SYNC,

TIMESTAMP, Emergency)
Object Dictionary
Application object
Communication object
(Server / Client SDO)
I/O
Communication object
(Receive/ Transmit PDO)
CAN bus
Application object
Process
Object Dictionary
Index 0000 0001 001F 0020 003F 0040 005F 0060 007F 0080 009F 00A0 0FFF 1000 1FFF 2000 5FFF 6000 9FFF A000 FFFF Object Not used Static Data Types Complex Data Types Manufacturer Specific Data Types Device Profile Static Data Types Device Profile Complex Data Types Reserved Communication Profile Area Manufacturer Specific Profile Area Standardized Profile Area Reserved
Object Dictionary Entries

Index 1000 1001 1002 1003 Object VAR VAR VAR ARRAY Name Device Type Error Register Manufacturer Status Reg Pre-defined error field Server SDO Comm Parameter Read 8 input lines Data Type UNSIGNED32 UNSIGNED8 UNSIGNED32 UNSIGNED8 Access Attribute RO RO RO RO Mandatory(M) or Optional (O) M M O O
1200
RECORD
SDO COMM PAR
RW
6000
ARRAY
UNSIGNED8
RO
Service Data Objects (SDOs)

Client
Bytes 4 .. 7
Data
Byte 3
Sub-Index
Bytes 1, 2
Index
S 0
Data Byte 1
E 1 N 3 .. 2 X 4 CCS 7 .. 5
ID 601
(e.g.)
Server
Client Command Byte
ID 581
(e.g.)
Byte 0
SCS 7 .. 5 X 4 .. 0
Bytes 1, 2
Index
Byte 3
Sub-Index
Bytes 4 .. 7
Reserved
Server Command Byte
Example: Expedited SDO download
Process Data Objects (PDOs)
Producer
Consumer
indication
request
Bytes 0 to 8
Process Data
ID
385 (example)
Example: Asynchronous PDO
CANopen state machine

Power- ON / Hardware Reset
Initialization
Init Done. Automatic transition to Preoperational state.
Pre-operational
Start Remote Node indication Enter Preoperational state indication
Stopped
Start Remote Node indication
Operational
Stop Remote Node indication
Network Management : Master-Slave Model

Bootup Mandatory standard method of starting operation of a CANopen network. Module Control Initialization of NMT Slaves. Global control of application data exchange Error Control Heartbeat / Node Guarding NMT Master monitors status of NMT slaves Life Guarding NMT Slaves detect failures in NMT master
Electronic Data Sheet (EDS)

Configuration of CANopen devices
Electronic Data Sheet (EDS): Template for a device from a particular vendor Manufacturer-independent standardized tools Device Configuration File (DCF): Incarnation of configured device (includes bit-rate and node id)
EDS
Managing project information on different platforms Designing networks with CANopen devices
Device and Application Profiles

Device Profiles
Defines the interface of a single device Object Dictionary Layout Specifies mandatory and optional device functionality
Application Profiles
Specification of required and optional devices in a system Communication interface between devices
Extensions via vendor specific profile range
Examples
Device Profiles
CiA 401 CANopen device profile for generic I/O modules CiA 402 CANopen device profile for drives and motion control CiA 425 Set of device profiles for medical add-on devices
Application Profiles
CiA 423 Application profile for rail vehicle power drive systems CiA 436 Application profile for construction machineries
Device Configuration
EDS
Template for different configurati ons for one device type
DCF
ID=2 250Kbps
Device
ID=110 500 Kbps
DEBUGGING TOOLS
CAN Tools: CAN Analyser
CANopen analysis and Configuration
Example: Medical
Leading Medical Electronics companys Gantry Controller
Gantry - part of CT scanner with multiple sensors and actuators Automated with CAN and CANopen
OCTRIANs VxWorks 6.9.x CAN driver with POSIX interface OCTRIANs VxWorks port of CANopen stack Hardware used: ARM processor with on-chip CAN controllers
CAN Interfaces
Ideal Stack for Real-Time Devices
Real Time Network
CANopen CAN drivers
Application
Operating System [VxWorks] Hardware
Octrian Enables Fast Time to Market

Readily Available Drivers and Stacks
CAN Driver Support for VxWorks

iMX6 TI AM335X IXXAT PCI , PCIe, PC104Plus cards PEAK Systems PCI, PCIe, PC104Plus cards KVASER PCI, PCIe, PC104Plus cards
CANopen stack on VxWorks

iMX6 TI AM335X IXXAT PCI , PCIe, PC104Plus cards PEAK Systems PCI, PCIe, PC104Plus cards KVASER PCI, PCIe, PC104Plus cards
Active Wind River + Octrian Engagements

Large Manufacturer: Industrial Automation
Fluid mixing system with many sensors and actuators with hard real-time (millisecond accuracy) requirements
Large Manufacturer: Medical Devices

External pace maker Gantry controls
Octrian: Wind River Strategic Partner
World leader in embedded and mobile software.
Expert in VxWorks and Linux for CAN Drivers and Protocol Stacks
Stephen Olsen Stephen.Olsen@WindRiver.com.
Lalita Godbole Lalita@Octrian.com

Can Canopen

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Can Canopen

Enviado por

Direitos autorais:

Formatos disponíveis

CAN and CANopen: Interconnecting Embedded Devices to enable the Internet of Things

2013 Wind River and Octrian All Rights Reserved

2013 Wind River and Octrian All Rights Reserved

2013 Wind River and Octrian All Rights Reserved

Open protocols based on CAN

2013 Wind River and Octrian All Rights Reserved

Distributed Application Design

Welding gun Robot arm

Welding gun Robot arm

2013 Wind River and Octrian All Rights Reserved

Welding gun Robot arm

2013 Wind River and Octrian All Rights Reserved

Implementation Step 1: Determine messages

Implementation Step 2: Define messages

Weld commands Position commands Proximity values Temperature readings

2013 Wind River and Octrian All Rights Reserved

Implementation Step 3: Sending messages

Welding gun Robot arm

Implementation Step 4: Receiving messages

Welding gun Robot arm

Implementation Step 5: Error conditions

Monitoring system Sound alarm

Off Freeze Welding gun Robot arm

Bus Protocol Criteria

Warning! I hear: Move backward Disturbance

I say: Move forward

2013 Wind River and Octrian All Rights Reserved

CAN Physical Layer

2013 Wind River and Octrian All Rights Reserved

Twisted pair carries the signal

2013 Wind River and Octrian All Rights Reserved

Physical Link Layer

Differential Voltages are interpreted as bits of data

2013 Wind River and Octrian All Rights Reserved

2013 Wind River and Octrian All Rights Reserved

CAN Flexible Data-Rate (CAN FD)

Receiver ACKs CRC delimiter

2013 Wind River and Octrian All Rights Reserved

2013 Wind River and Octrian All Rights Reserved

Speed control messages Temperature readings

I need speed control messages, brake commands, and temperature readings

I need speed control messages and diagnostic information

2013 Wind River and Octrian All Rights Reserved

0x101 Higher priority

Speed control messages Temperature readings

2013 Wind River and Octrian All Rights Reserved

High priority message is on network. Try again when bus is idle.

Yes Yes Ignore

2013 Wind River and Octrian All Rights Reserved

1 bit: Start signal

0 8 bytes: Data 16 bits: Checksum 2 bits: Acknowledge

11 or 29 bits: Message identifier

6 bits: Number of data bytes (0 8)

2013 Wind River and Octrian All Rights Reserved

Error signal detected Resending Sending error signal

2013 Wind River and Octrian All Rights Reserved

2013 Wind River and Octrian All Rights Reserved

Bus monitoring error

Signal received violates bit-stuffing rule

2013 Wind River and Octrian All Rights Reserved

2013 Wind River and Octrian All Rights Reserved

2013 Wind River and Octrian All Rights Reserved

Use industry standard socket interface

Provide various socket level filters for CAN messages.