Image Processing Reference
In-Depth Information
specifications dictated by the OEM for what concerns both the physical (e.g., bit-timing) and
higher-layer protocols. While trucks and buses mostly rely on J-based specifications, propri-
etary higher-layer protocols and profiles are usually adopted in passenger cars. As an exception,
CAN-based diagnostics interfaces to scanner tools usually comply with ISO standards.
15.1.2 CAN in Automation and Embedded Systems
Even though it was conceived explicitly for vehicle applications, at the beginning of the s CAN
began to be adopted in different scenarios, too. he standard documents provided satisfactory spec-
ifications for the lower communication layers but did not offer guidelines or recommendations for
the upper part of the Open Systems Interconnection (OSI) protocol stack, in general, and for the
application layer in particular. This is why the earlier applications of CAN outside the automotive
scenario (i.e., textile machines, medical systems, and so on) adopted “ad hoc” monolithic solutions.
The “CAN in Automation” (CiA) users' group, founded in , was originally concerned with the
specification of a “standard” CAN application layer (CAL). his effort led to the development of the
general-purpose CAL specification. CAL was intended to fill the gap between the distributed applica-
tion processes and the underlying communication support but, in practice, it was not successful, the
main reason being that, as CAL is really application-independent, each user had to develop suitable
profiles for his/her specific application fields.
Inthesameyears,Allen-BradleyandHoneywellstartedajointdistributedcontrolprojectbasedon
CAN. Although the project was abandoned a few years later, Allen Bradley and Honeywell continued
their works separately and focused on the higher protocol layers. he results of those activities were
the Allen-Bradley DeviceNet solution and the honeywell smart distributed system (SDS). For a num-
ber of reasons SDS remained, in practice, a solution internal to Honeywell Microswitch, while the
development and maintenance activities for DeviceNet were soon switched to the Open DeviceNet
Vendor Association (ODVA). Thereafter, DeviceNet has been widely adopted in the United States
in a number of factory automation areas, so becoming a serious competitor to widespread solutions
such as PROFIBUS-DP and INTERBUS.
Besides DeviceNet and SDS other significant initiatives were focused on CAN and its applica-
tion scenarios. CANopen was conceived in the framework of the European Esprit project ASPIC
by a consortium led once again by Bosch GmbH. The purpose of CANopen was to define a profile
based on CAL, which could support communications inside production cells. he original CANopen
specifications were further refined by CiA and released in .
Later on, CANopen, DeviceNet, and SDS became European standards, CANopen as an embedded
network for machine-distributed control and the other two for factory and process automation.
In particular, they are defined in standard EN [EN], where part is about DeviceNet [EN],
part deals with SDS [EN], and part describes CANopen [EN].
15.2 CAN Protocol Basics
The CAN protocol architecture is structured according to the well-known layered approach foreseen
by the ISO OSI model. However, as in most currently existing networks conceived for use at the
field level in the automated manufacturing environments, only few layers have been considered in its
protocol stack. his is to make implementations more efficient and inexpensive. Few protocol layers,
in fact, imply reduced processing delays when receiving and transmitting messages, as well as simpler
communication software.
CAN specifications [ISO] [ISO] [ISO], in particular, include only the physical and data-link
layers, as depicted in Figure .. ..The physical layer is aimed at managing the effective transmission of
data over the communication support, and tackles the mechanical and electrical aspects. Bit-timing
and synchronization, in particular, belong to this layer.
