2. Objective
• A new trend for Hospital Environment that
consist combination of RTOS (Real time
operating System) and CAN (Control area
network) communication.
3. Abstract
• Normally Hospital consists number of ECU, Sensors
and Control unit. all are interconnected with wiring.
• This very difficult to read data from device, so we are
proposing new system that consist RTOS with CAN
communication. Due to this system we will read the
data from sensors at a time, because RTOS consist
Multitasking with Kernel and we can give the
information to Driver using CAN communication. It is
a high Speed communication bus and by using this we
can do the communication between High power Device
(like AT89C51, ARM,PIC…etc).
12. What is CAN and what are some of its
features?
• Serial communication
• Multi-Master Protocol
• Compact
– Twisted Pair Bus line
• 1 Megabit per second
13. • Why is CAN used?
– Robust in noisy environments
– Priority Signal Setting
– All devices on the network receive every bit of
information sent on the BUS
– Cost Effective
14. • What are some real world applications of CAN?
– Controller Area Networks are used in many different
fields, the bulk of which are
• Auto-motive industry
• Factory Automation
• Machine Control
• Medical Equipment and devices
• And more….
15. What is transmitted?
Field name Length (bits) Purpose
Start-of-frame 1 Denotes the start of frame transmission
Identifier 11 A (unique) identifier for the data
Remote transmission request (RTR) 1 Must be dominant (0)Optional
Identifier extension bit (IDE) 1 Must be dominant (0)Optional
Reserved bit (r0) 1
Reserved bit (it must be set to dominant (0), but accepted as either dominant or
recessive)
Data length code (DLC) 4 Number of bytes of data (0-8 bytes)
Data field 0-8 bytes Data to be transmitted (length dictated by DLC field)
CRC 15 Cyclic redundancy check
CRC delimiter 1 Must be recessive (1)
ACK slot 1 Transmitter sends recessive (1) and any receiver can assert a dominant (0)
ACK delimiter 1 Must be recessive (1)
End-of-frame (EOF) 7 Must be recessive (1)
• All messages sent over a CAN network follows this
format. Each bit is used either to verify the validity
of the message, or is data itself.
16. What is the process of sending a
message?
• At each CAN device, the
start of frame bit
notifies a transmission
is being sent.
• The identifier bit shows
the priority of the
message along with
determining which
device the data belongs
to.
18. Basic message frame format
Field name
Length
(bits) Purpose
Start-of-frame 1 Denotes the start of frame transmission
Identifier 11 A (unique) identifier for the data
Remote transmission request (RTR) 1 Must be dominant (0)
Identifier extension bit (IDE) 1 Must be dominant (0)
Reserved bit (r0) 1
Reserved bit (it must be set to dominant (0), but accepted
as either dominant or recessive)
Data length code (DLC) 4 Number of bytes of data (0-8 bytes)
Data field 0-8 bytes Data to be transmitted (length dictated by DLC field)
CRC 15 Cyclic redundancy check
CRC delimiter 1 Must be recessive (1)
ACK slot 1
Transmitter sends recessive (1) and any receiver can
assert a dominant (0)
ACK delimiter 1 Must be recessive (1)
End-of-frame (EOF) 7 Must be recessive (1)
20. Message Objects
• 32 message objects
• Configured to transmit or receive or both
• Configured using the Message Object Interface Registers
• Each identifier is stored in a Message object.
• Message number is the receive/transmit priority for the
Message Objects
– Message Object 1 has the highest priority, while Message Object 32
has the lowest priority
21. Message Object Interface register
• ID28-0 Message Identifier
– ID28 - ID0 29-bit Identifier (“Extended Frame”).
– ID28 - ID18 11-bit Identifier (“Standard Frame”).
• Dir Message Direction
– one Direction = transmit
– zero Direction = receive
• Data 0 1st data byte of a CAN Data Frame
• Data 1 2nd data byte of a CAN Data Frame
25. REFERENCES
[1] N. Boules, "Reinventing the Automobile: The Cyber-Physical Challenge",
from Embedded Systems to Cyber-Physical Systems: a Review of the
State-of-the-Art and Research Needs Workshop, St. Louis, MO, April,
2008.
[2] K. R. Pattipati, A. Kodali, K. Choi, S. Singh, C. Sankavaram, S. Mandal
W. Donat, S.M. Namburu, S. Chigusa, L. Qiao and J. Luo, "An integrated
diagnostic process for automotive systems," in D. Prokhorov, (ed.) Studies
in Computational Intelligence (SCI), Vol. 132, 2008.
[3] C. Sankavaram, A. Kodali, D. F. M. Ayala, K. Pattipati, S. Singh, and P.
Bandyopadhyay, “ Event-driven data mining techniques for automotive
fault diagnosis”, 21st Intl. Workshop on Principles of Diagnosis, Portland,
OR, October 2010.
[4] C. Sankavaram, B. Pattipati, A. Kodali, K. Pattipati, M. Azam, and S.
Kumar, "Model-based and data-driven prognosis of automotive and
electronic systems", 5th Annual IEEE Conference on Automation Science
and Engineering, Bangalore, India, August 22-25, 2009.
[5] J. Luo, H. Tu, K. Pattipati, L. Qiao, and S. Chigusa, “Graphical models for
diagnostic knowledge representation and inference,” IEEE Instrument and
Measuremen