Arduino MKR WiFi 1010 Board

Arduino MKR CAN Shield

The MKR WIFI 1010 is equipped with an ESP32 module from U-BLOX. It speeds up and simplifies prototyping of WiFi based IoT  It aims to speed up and simplify the prototyping of WiFi based IoT applications using the ESP32 module and low power consumption. The board is composed of three main blocks:

• SAMD21 Cortex-M0+ 32bit Low Power ARM MCU;
• U-BLOX NINA-W10 Series Low Power 2.4GHz IEEE 802.11 b/g/n Wi-Fi
• ECC508 Crypto Authentication

The MKR WIFI 1010 includes 32-bit computational power, a rich set of I/O interfaces, and low power Wi-Fi with a Cryptochip for secure communication using SHA-256 encryption.

The Arduino Software (IDE) simplifies code development and programming. Ideal for IoT battery-powered projects in a compact form.

Its USB port can be used to supply power (5V) to the board. It has a Li-Po charging circuit that allows the Arduino MKR WIFI 1010 to run on battery power or an external 5 volt source, charging the Li-Po battery while running on external power. Switching from one source to the other is done automatically.

With this shield you can easily connect to a CAN (Controller Area Network) Bus. Discover new possibilities of interaction between your Arduino MKR Board and the CAN ecosystem.

The MKR CAN shield can simplify the connection of the MKR boards with industrial systems and especially with automotive applications.

This shield opens a new set of possible applications like smart vehicles, autonomous cars and drones. A CAN connection also provides the possibility to connect a MKR board directly with several types of industrial grade sensors, motors and displays.

The MKR CAN shield allows a MKR board to connect to the CAN bus using the MCP2515 SPI to CAN chip.

The Arduino MKR CAN Shield uses the MCP2515 chip by Microchip. This chip is an industry standard.

The switch close to the CAN bus connector allows to enable or disable the termination resistor.

Each Arduino Engineering Kit includes:

BOARDS

• 1 Arduino MKR1000 Board
• 1 Arduino MKR Motor Shield
• 1 Arduino MKR IMU Shield

ELECTRICAL COMPONENTS

• 1 DC Motor
• 2 Geared DC Motors with Encoder
• 1 Standard Micro Servo (180 degrees)
• 1 Hall Sensor Module
• 1 Ultrasonic Sensor Module
• 1 Webcam
• 1 LiPo Battery
• 1 LiPo Battery Charger
• 1 Micro USB Cable
• 1 3-pin to 4-pin Tinkerkit Module Cable
• 1 3-pin Tinkerkit Module Cable MECHANICAL

COMPONENTS

• 3 Sets of Assembly Pieces
• 2 Wheels
• 1 Caster Wheel
• 1 Timing Belt
• 2 Timing Pulley
• 2 DC Motor Mounting Brackets
• 1 Metal Shaft (90mm)
• 2 Metal D Shafts (50mm)
• 2 Sets of Distance Spacers (6mm, 17mm)
• 2 Sets of M2 Bolts (10mm, 25mm)
• 3 Sets of M3 Bolts (10mm, 15mm, 25mm)
• 1 Set of M2 Nuts
• 1 Set of M3 Nuts
• 1 Set of M3 Lock Nuts with Nylon Insert
• 3 Shaft Collars
• 1 Propeller Adapter Screw
• 2 Magnets Ø8 mm
• 1 Thread 5m
• 2 Whiteboard Pens
• 1 Sticker for Vision Recognition

The Arduino Engineering Kit is the ideal solution for university students, providing a state-of-the-art, hands-on incorporation of Arduino technology in an educational setting.

The kit is primarily for three types of users:

• Students learning about engineering at a university or at a vocational school (e.g., Introductory Engineering, Controls, Mechatronics courses);
• Professors teaching engineering who also want practical resources to demonstrate engineering concepts;
• Makers with an interest or background in engineering, either professionally or as a hobby.

The Arduino Engineering Kit covers fundamental engineering concepts, key aspects of mechatronics, and MATLAB and Simulink programming.Included projects challenges students intellectually and helps develop physical engineering skills — and they’re just fun to do.

• Self-Balancing Motorcycle This motorcycle will maneuver on its own on various terrains and remain upright using a flywheel for balance. It’s very exciting to build and to see in action.
• Mobile Rover This vehicle can navigate between given reference points, move objects with a forklift and much more. It’s very fun to make and use.
• Whiteboard Drawing Robot This amazing robot can take a drawing it’s given and duplicate it on a whiteboard. It’s most impressive.

The kit is sold in a hard plastic, stackable tool box for storage and years of reuse. Inside the box is an easy-to-use Arduino MKR1000 board, several customized parts, and a complete set of electrical and mechanical components needed to assemble all three projects

What is CAN (Control Area Network)?

CAN (Control Area Network), also referred to as CAN bus, is a communication protocol initially developed as a vehicle bus standard to allow MCUs to communicate with each other without the need for a host.

Although originally intended for automotive, CAN bus is used in a diverse number of industries due to its extreme reliability and robustness:

• Building Automation
• Aerospace (satellites)
• Railways (trams, undergrounds, light railways, and long distance trains)
• Medical (lights, tables, cameras, x-ray machines)
• Lifts and escalators
• Laboratory Equipment
• Sports Cars
• Automatic Doors
• Telescopes
• Gambling Machines

CAN is a message-based protocol that defines how data is transferred from one device to another in a network.  It was designed specifically for the automotive industry, where an increasing number of electronic devices used communication signals with more complex interrelations between them, making life difficult for the automobile engineers tasked with designing systems using point to point wiring.

Some of the benefits of CAN include:

• Extreme Reliability and Robustness
• No Message Collision
• Very Low Resource Requirements
• Low-Cost Implementation
• Designed for Real-Time Applications
• Short Error Recovery Time

Edit media

Dimensions x Small Medium Large Custom

Subject (required) Brief Description Tags (separated by comma) Video visibility in search results Visible Hidden

Parent content

Winners Announcement: Auto Hacks and Beyond: Show Us How You Would Use the Arduino MKR WiFi 1010 Board and CAN Shield!

Poster

Upload Preview

Ok

Cancel

CAN facilitates multi-domain communication.  A domain is a set of technologies that have similar requirements.  Climate control, wipers, etc would form one domain while stereo, GPS, display, etc. would form another domain.  Every node, or electronic device, which needs to communicate through CAN protocol connects with one another through a common serial bus in order to transmit and receive messages.

For the data exchange to occur, each node must have the necessary hardware and software embedded in them.  In automobiles, these embedded systems are known as electronic control units (ECU).

Where Did CAN Come From?

When most people think of Controller Area Network (CAN), they think of what it was originally designed for,  allowing embedded systems, located throughout an automobile, to communicate over a network and work together for specific applications such as controlling emissions or deploying airbags. An embedded system is a programmed controlling and operating system designed for one or a few specific functions.  The system is embedded as part of a complete device including hardware and mechanical parts and they are used to control one or more electrical systems or subsystems within a vehicle. Examples of ECUs include the Engine Control Module (ECM), Powertrain Control Module (PCM), Transmission Control Module (TCM), Anti-Lock Braking Systems (ABS), Central Control Module (CCM), Central Timing Module (CTM), General Electronic Module (GEM), Body Control Module (BCM), Suspension Control Module (SCM), Speed Control Unit (SCU), and Electric Power Steering Control Unit (PSCU).

Before ECUs began appearing in automobiles in the 1970s, every component from the engine to the windows, steering, brakes, was a mechanical component, working on the principles of mechanics.  Mechanical systems have their inherent limitations and limited accuracy, not only causing undetected failures, but posing life threats to the consumer.

In 1968, Volkswagen became the first to use an embedded system in an automobile when it used an electronic fuel injection (EFI) system that was manufactured by Bosch. ECUs have become standard in most vehicles since the late 70s due to increasingly stringent emission standards. Before that time, it was possible to build your engine without microprocessors.  With the enactment of increasingly stricter emissions laws, sophisticated control schemes were needed to regulate the air/fuel mixture so that the catalytic converter could remove a lot of the pollution from the exhaust. Because controlling the engine is the most processor-intensive job on your car, and the engine control module (ECM) will be the most powerful computer on most cars. ECM uses a closed-loop control, a control scheme that monitors outputs of a system to control the inputs to a system, managing the emissions and fuel economy of the engine (as well as a host of other parameters). Gathering data from dozens of different sensors, the ECM knows everything from the coolant temperature to the amount of oxygen in the exhaust. With this data, it performs millions of calculations per second, performing complex calculations to find the best spark timing and determine how long to keep the fuel injector open. It does all of this to ensure the lowest emissions and best mileage.

Electronic control units (ECU) typically get their input from sensors (for speed, temperature, pressure, etc) which it then uses for computation. Various actuators are used to enforce applications determined by the ECU such as turning the cooling fan on or changing the gear. In order to perform these applications, ECU must exchange information amongst themselves during the normal operation of the vehicle. For example, the engine needs to tell the transmission what the engine speed is, and the transmission needs to tell other modules when a gear shift occurs. The development of the vehicle network arose from the need to exchange data between ECUs quickly and reliably. Point-to-point wiring was the only way to connect ECU to one another.  It had not only became increasingly complex, it required alterations depending on which modules were included with a vehicle. A car without Anti-Lock Braking Systems (ABS) would require different wiring then a car that included this module.

The need for a vehicular central network for automobiles became increasingly transparent due to the complex wiring of ECU, which would require alteration depending on what ECU were added or removed. A central network would allow you to simply plug an ECU into central network and any ECU that is added could talk to any other ECU that is part of the network. Such a design would be easily manufacturable, easier to maintain, and would not require altering the vehicle's entire wiring architecture every time an ECU was added or removed. Each ECU would be a node on the vehicle's network, controlling specific components related to its functions and communicating with other ECUs for shared applications, through a standard protocol over the vehicular network.

A central vehicular network required the following needs:

• Low cost
• Immunity from external noise
• Ability to operate in harsh environments
• Overall robustness and reliability

Before CAN bus, wire-to-wire harnessing could contain miles of harnessing, with bundles of 8 or more wires to carry various signals to interconnected systems.

In the early 80s, engineers at the Robert Bosch Gmbh, were evaluating using existing serial bus systems in vehicles. Because none of the available network protocols met the needs of a vehicular network, Uwe Kiencke started development of a new serial bus system in 1983.  The new bus protocol was intended to add new functionalities, reduction of wiring harnesses was a byproduct of the development of CAN.  Engineers from Mercedes-Benz were involved during the early specification phase of the new serial bus system, so too was Intel, as a potential main semiconductor vendor. A consultant, Professor Dr. Wolfhard Lawrenz from the University of Applied Science in Braunschweig-Wolfenbüttel, Germany, gave the network the name 'Controlled Area Network' In 1986, the protocol was officially released at the Society of Automotive Engineers (SAE) conference in Detroit, Michigan.

The multi-master network was introduced by Uwe Kiencke, Siegfried Dais, and Martin Litschel.  With no central bus master, it is based on a non-destructive arbitration mechanism, granting bus access to the message with highest priority without any delays. It implemented several error detection mechanisms such as automatic disconnection of faulty bus nodes in order to keep up communication between remaining nodes. Transmitted messages were not identified by the node address of the transmitter or the receiver of the message, unlike almost any other bus system, but rather their content. The identifier used to represent the content of the message specified the priority of the message within the system. In mid 1987, the first implementation of the CAN protocol in hardware was delivered by Intel, the 82526 CAN Controller chip. Philips Semiconductors introduced the 82C200 shortly after. Both CAN controllers had different methods of acceptance filtering and message handling. The FullCAN method used by Intel required less CPU load from connected microcontrollers but was limited regarding the number of messages that could be received. Today's CAN controllers use a mixture of both concepts of acceptance filtering and message handling.

In 1991, the Mercedes-Benz W140 became the first production vehicle to feature a CAN-based multiplex wiring system. Also in 1991, Bosch published the latest CAN specification, CAN 2.0. It consisted of two parts; part A is for the standard format with an 11-bit identifier, and part B is for the extended format with a 29-bit identifier. A CAN device that uses 11-bit identifiers is commonly called CAN 2.0A and a CAN device that uses 29-bit identifiers is commonly called CAN 2.0B. These standards are freely available from Bosch along with other specifications and white papers.

In 1993, the International Organization for Standardization (ISO) released the CAN standard ISO 11898 which was later restructured into two parts; ISO 11898-1 which covers the data link layer, and ISO 11898-2 which covers the CAN physical layer for high-speed CAN. ISO 11898-3 was released later and covers the CAN physical layer for low-speed, fault-tolerant CAN. The physical layer standards ISO 11898-2 and ISO 11898-3 are not part of the Bosch CAN 2.0 specification. These standards may be purchased from the ISO. Bosch is still active in extending the CAN standards. In 2012, Bosch released CAN FD 1.0 or CAN with Flexible Data-Rate. This specification uses a different frame format that allows a different data length as well as optionally switching to a faster bit rate after the arbitration is decided. CAN FD is compatible with existing CAN 2.0 networks so new CAN FD devices can coexist on the same network with existing CAN devices. CAN bus is one of five protocols used in the on-board diagnostics (OBD)-II vehicle diagnostics standard.

The OBD-II standard has been mandatory for all cars and light trucks sold in the United States since 1996. The EOBD standard has been mandatory for all petrol vehicles sold in the European Union since 2001 and all diesel vehicles since 2004.

Automotive Applications

A modern automobile has as many as 70-80 electronic control units (ECU) for various subsystems, with the engine control unit having the biggest processor. ECUs are used for transmission, airbags, antilock braking/ABS, cruise control, electric power steering, audio systems, power windows, doors, mirror adjustment, battery and recharging systems for hybrid/electric cars, etc. Some of these form independent subsystems, but communications among others are essential. The CAN standard allows these subsystems to control actuators or receive feedback from sensors.  Examples include:

• Auto/Start - Various sensor inputs from around the vehicle (speed sensors, steering angle, air conditioning on/off, engine temperature) are collated via the CAN bus to determine whether the engine can be shut down when stationary for improved fuel economy and emissions.
• Electric park brakes: The "hill hold" functionality takes input from the vehicle's tilt sensor (also used by the burglar alarm) and the road speed sensors (also used by the ABS, engine control and traction control) via the CAN bus to determine if the vehicle is stopped on an incline. Similarly, inputs from seat belt sensors (part of the airbag controls) are fed from the CAN bus to determine if the seat belts are fastened, so that the parking brake will automatically release upon moving off.
• Parking assist systems: when the driver engages reverse gear, the transmission control unit can send a signal via the CAN bus to activate both the parking sensor system and the door control module for the passenger side door mirror to tilt downward to show the position of the curb. The CAN bus also takes inputs from the rain sensor to trigger the rear windscreen wiper when reversing.
• Auto lane assist/collision avoidance systems: The inputs from the parking sensors are also used by the CAN bus to feed outside proximity data to driver assist systems such as Lane Departure warning, and more recently, these signals travel through the CAN bus to actuate brake by wire in active collision avoidance systems.
• Auto brake wiping: Input is taken from the rain sensor (used primarily for the automatic windscreen wipers) via the CAN bus to the ABS module to initiate an imperceptible application of the brakes whilst driving to clear moisture from the brake rotors. Some high performance Audi and BMW models incorporate this feature. Sensors can be placed at the most suitable place, and its data used by several ECU. For example outdoor temperature sensors (traditionally placed in the front) can be placed in the outside mirrors, avoiding heating by the engine, and data used by both the engine, the climate control and the driver display.

When an ECU in a car needs a signal, that is where the CAN comes in. The CAN bus network allows data from sensors and embedded systems to circulate around a car at all times. Each embedded system transmits all its system and programming information constantly, as many as 2000 signals are floating around the network at any time, whether they are being requested or not. With no central hub or routing system, every ECU in the network listens and plucks out what it needs to carry out its work, from a continuous flow of information.

CAN does not follow the master-slave architecture which means every nodes has the access to read and write data on the CAN bus. When the node is ready to send data, it checks availability of the bus and writes a CAN frame onto the network. A frame is defined structure, carrying meaningful sequence of bit or bytes of data within the network. CAN transmitted frame does have address neither of transmitting node or the receiving node.  CAN does not follow the master-slave architecture which means every nodes has the access to read and write data on the CAN bus. When the node is ready to send data, it checks availability of the bus and writes a CAN frame onto the network. A frame is defined structure, carrying meaningful sequence of bit or bytes of data within the network. CAN transmitted frame does have address neither of transmitting node or the receiving node.

In recent years, the LIN bus standard has been introduced to complement CAN for non-critical subsystems such as air-conditioning and infotainment, where data transmission speed and reliability are less critical.

Can Bus in Manufacturing

CAN is one of the most reliable methods for transmitting real-time data. This is attractive in manufacturing where unreliable data communication can have a direct impact on production. Any breakdown in error communication can also mean errors go undetected. A minor maintenance issue such as a loose arm could turn into a much larger issue down the line such as damage to product or machinery. The reliability of CAN is further bolstered by the impossibility of message collision and short error recovery time which help mitigate the likelihood of large delays or damage to equipment.

Some of the benefits of CAN include:

• Extreme Reliability and Robustness
• No Message Collision
• Very Low Resource Requirements
• Low-Cost Implementation
• Designed for Real-Time Applications
• Short Error Recovery Time

However, a major drawback to using CAN for industrial use is the protocol's limited bit rate in relation to the network. CAN communication can reach up to 1 megabit per second at a cable length of 40 meters.

Some of the disadvantages include

• Limited network length
• Limited baud rate of 1 MBit/sec
• Limited Bandwidth

By comparison, industrial ethernet offers speeds of up to 100 megabits per second at higher network lengths. However, Ethernet is far less reliable.  CAN already has extensive use in legacy industrial automation, so it can also be very costly to retrofit existing systems with Ethernet.

Can Bus in Elevators

The low-cost and reliability of Can Bus is used in elevator technology, where safety is critical and cost-containment is an on-going concern.  Can Bus, due to its serial technology, allows you to significantly reduce the wire count in the traveling cable, machine room, and throughout the building. Less wiring and fewer terminations ease fire loading and troubleshooting.  Elevators that are used in commercial or multi-family occupancies must contend with large groups of people interacting with powerful machinery to lift them off the ground. Also, usage is spread around all times of the day, year round.

A case in point is elevator technology, which continues each decade to write the book on reliability and safety all the while with a view on initial and on-going cost containment. CAN Bus, because of its serial technology, makes possible significantly reduced wire count in the traveling cable, machine room and throughout the building. Fire loading and troubleshooting difficulties are eased with less wiring and fewer terminations. Phone-style connectors allow easy field expansion.

An essential element in elevators as used in commercial and multifamily occupancies is that humans in large numbers and often including children and disabled or infirm individuals are interacting with powerful machinery that lifts them off the ground. This happens day and night, year round, and in the fullness of time there is the potential for equipment failure and injury to the interacting individuals. This hazard is greatly mitigated by means of the reliability that is built into CAN Bus technology.

Think of all the things that could go wrong in elevators used in large high-rise buildings!  You could have many elevator cabs going in motion at the same time, traveling in opposite directions, either reducing speed as they prepare to stop at a floor or accelerating after making a complete stop, all the while doors are opening and closing as needed.

The elevator cab responds in a pre-programmed, prioritized manner to call buttons that are pressed on many different floors, as well as, buttons pressed inside the cab. The simple, yet highly effective system of message management within the Can Bus is what makes this all possible. Every node is connected to one another through a two-wire bus. Each node requires a (local) central processing unit to determine which messages get transmitted. These messages are received by sensors, actuators, and control devices that are connected to the CAN bus. The CAN controller stores the received bits that are sent from the bus until the message is complete and it is made available to the host processor.

Using CAN, all nodes are available to receive messages but this can not happen simultaneously.  Data transmission for Can bus attains content resolution through means of arbitration. Binary bits values are termed dominant and recessive bits with "0" being dominant and "1" being recessive. The dominant bit always overwrites the recessive bit. Each message, packet of data that is exchanged between the nodes, has a unique identification number.  Because the identification number is unique to all nodes within the network, when a transmitting node places data on the network, it checks the unique id to pass the message through the filter and the rest are ignored. Messages in CAN are sent in a format called frames, a defined structure that carries a meaningful sequence of bits or bytes of data within a network. A Standard CAN frame is 11 bit identifier field while an extended CAN frame has a 29 bit identifier field.

Arbitration is the means by which conflict is resolved when two or more nodes receive a message at the same time. Whenever a bus is free, any unit can transmit a message. .During arbitration every transmitter compares the value of transmitted bit with the bit value on the bus. If the bit value is same, the node continues to send the bits. But at any time, if the transmitted bit value is different from bus value, the dominant bit overwrites the recessive bits. The arbitration field of the CAN message consists of an 11- or 29-bit identifier and a remote transmission (RTR) bit. The identifier having lowest numerical value has the highest priority.  CAN bus therefore realizes real-time prioritization using a system of dominant (logic level 0) and recessive (logic level 1) messaging. Neither information nor time is lost using the process of arbitration.

When arbitration takes place, the lower priority message is not obliterated, as is the case in some other types of serial transmissions. The message survives and is retransmitted after an appropriate time interval. This is why CAN bus succeeds in real time prioritization for complex automotive, elevator and particle collider applications, and more.

Can Bus in Elevators

The low-cost and reliability of Can Bus is used in elevator technology, where safety is critical and cost-containment is an on-going concern.  Can Bus, due to its serial technology, allows you to significantly reduce the wire count in the traveling cable, machine room, and throughout the building. Less wiring and fewer terminations ease fire loading and troubleshooting.  Elevators that are used in commercial or multi-family occupancies must contend with large groups of people interacting with powerful machinery to lift them off the ground. Also, usage is spread around all times of the day, year round.

A case in point is elevator technology, which continues each decade to write the book on reliability and safety all the while with a view on initial and on-going cost containment. CAN Bus, because of its serial technology, makes possible significantly reduced wire count in the traveling cable, machine room and throughout the building. Fire loading and troubleshooting difficulties are eased with less wiring and fewer terminations. Phone-style connectors allow easy field expansion.

An essential element in elevators as used in commercial and multifamily occupancies is that humans in large numbers and often including children and disabled or infirm individuals are interacting with powerful machinery that lifts them off the ground. This happens day and night, year round, and in the fullness of time there is the potential for equipment failure and injury to the interacting individuals. This hazard is greatly mitigated by means of the reliability that is built into CAN Bus technology.

Think of all the things that could go wrong in elevators used in large high-rise buildings!  You could have many elevator cabs going in motion at the same time, traveling in opposite directions, either reducing speed as they prepare to stop at a floor or accelerating after making a complete stop, all the while doors are opening and closing as needed.

The elevator cab responds in a pre-programmed, prioritized manner to call buttons that are pressed on many different floors, as well as, buttons pressed inside the cab. The simple, yet highly effective system of message management within the Can Bus is what makes this all possible. Every node is connected to one another through a two-wire bus. Each node requires a (local) central processing unit to determine which messages get transmitted. These messages are received by sensors, actuators, and control devices that are connected to the CAN bus. The CAN controller stores the received bits that are sent from the bus until the message is complete and it is made available to the host processor.

Using CAN, all nodes are available to receive messages but this can not happen simultaneously.  Data transmission for Can bus attains content resolution through means of arbitration. Binary bits values are termed dominant and recessive bits with "0" being dominant and "1" being recessive. The dominant bit always overwrites the recessive bit. Each message, packet of data that is exchanged between the nodes, has a unique identification number.  Because the identification number is unique to all nodes within the network, when a transmitting node places data on the network, it checks the unique id to pass the message through the filter and the rest are ignored. Messages in CAN are sent in a format called frames, a defined structure that carries a meaningful sequence of bits or bytes of data within a network. A Standard CAN frame is 11 bit identifier field while an extended CAN frame has a 29 bit identifier field.

Arbitration is the means by which conflict is resolved when two or more nodes receive a message at the same time. Whenever a bus is free, any unit can transmit a message. .During arbitration every transmitter compares the value of transmitted bit with the bit value on the bus. If the bit value is same, the node continues to send the bits. But at any time, if the transmitted bit value is different from bus value, the dominant bit overwrites the recessive bits. The arbitration field of the CAN message consists of an 11- or 29-bit identifier and a remote transmission (RTR) bit. The identifier having lowest numerical value has the highest priority.  CAN bus therefore realizes real-time prioritization using a system of dominant (logic level 0) and recessive (logic level 1) messaging. Neither information nor time is lost using the process of arbitration.

When arbitration takes place, the lower priority message is not obliterated, as is the case in some other types of serial transmissions. The message survives and is retransmitted after an appropriate time interval. This is why CAN bus succeeds in real time prioritization for complex automotive, elevator and particle collider applications, and more.

Can Bus in Medical Technology

Because medical devices have become more sophisticated, manufacturers are sourcing parts from third parties in order to reduce development costs and meet their time-to-market requirements.  Third parties use open standards to simplify third party integration and to substitute products with alternatives from another manufacturer.  One such technology that has been used by several manufacturers is the use of the serial Controller Area Network (CAN) bus system as an embedded network for real-time control.  For most medical devices, the CANopen device profiles define a device finite state automaton (FSA). An FSA specifies device states, corresponding internal and external device behaviour and the events that cause a certain state transition.

So far, a device profile for X-ray collimators (CiA 412-2) has been developed jointly by GE Healthcare, Philips Medical Systems and Siemens Medical Solutions, under the CiA umbrella. The main task of an X-ray collimator is to limit the X-ray beam to a defined format. The device profile supports several functions for focusing the X-ray beam, such as rectangular or circular collimation. Furthermore, the specification makes it possible to support the use of filters for influencing the spectral characteristics of the X-ray beam. The visual simulation of the X-ray beam is functionally incorporated into this device profile too.

Philips Medical Systems has used CAN and CANopen as the command data communication technology in user interfaces, image detection, X-ray generation, X-ray collimation and the control of the mechanical moving parts of the X-ray system.  Dose measurement systems are another CANopen device profile. The dose measurement system is used to measure the X-ray dose, the dose area product, the entrance / skin dose and the corresponding dose rates in an X-ray machine. It also measures the irradiation time and factors that influence dose measurement, such as chamber temperature and air pressure. The CANopen device profile defines how the field values (actual measured values) are converted to the desired process values (desired measured value). Standards for a new class of device profiles for medical diagnostic add-on modules, such as contrast media injectors and Electro-Cardiograms (ECG), are being developed. The application profile for contrast media injectors covers devices used in angiography and those used with CT scanners. The profile also supports multi-piston injectors. The scanner or image-processing device always provides CANopen Manager functionality. The injector device functions as CANopen NMT slave device.

CANopen networks are now used in many medical and healthcare fields: in laboratory analysis equipment, for example. CANopen is also used in several automated Operating Rooms (OR) for endoscope surgery. Besides OR lighting, light projectors, cameras, insufflators (CO2) and HF scalpels have been equipped with CANopen interfaces. Device profiles for these have not yet been standardised, but CiA will do this when the market asks it to. Several manufacturers of patient beds for intensive care and OR tables are using CANopen as an embedded network to control various drives and human-machine interfaces. A standardized CANopen interface for beds that will facilitate communication with other intensive care devices as well as OR devices is under discussion.

Can Bus in Aerospace and Unmanned Air Systems (UAS)

Until recently, CAN was primarily implemented with proprietary protocols in the aerospace field.  The acceptance of CAN technology by Airbus, an international pioneer in the aerospace industry, and Boeing has led to ARINC 825, a standard for Control Area Network bus protocol for airborne use to take off.  ARINC 825, a higher-level protocol for addressing  provides addressing mechanisms, communication mechanisms, profile descriptions, service structure, and more. It is also the basis o fa number of application specific protocols such as ARINC 810 and 812 which specify communication between modules in the galley with a focus on power management.  ARINC 826, a protocol for avionic data loading over a Controller Area Network bus, specifies Software Data Loading over CAN.

Controllers that are connected to the CAN bus transmit data to the bus and receive data from the bus.  Data collisions on the bus are avoided by using the CSMA/AMP (Carrier Sense Multiple Access with Arbitration on Message Priority) technique. This is a means of prioritizing messages whereby a transmitter broadcasts a message to all CAN nodes whereupon a each node decides, based on the identifier received, whether to process the message or not. The identifier is also used to determine the priority the message is given to access the bus.  While there is no theoretical limit to the number of terminals that can be connected to the bus, it is normally limited to 32 to avoid data delay.

CAN bus in order to reduce the number of interconnecting wires from the control panel in the flight deck to system computers in the avionics compartment. The typical overhead panel may have 14 to 15 switches and indicators, with each switch having six wires, for a total of at least 90 wires running from the flight deck to the avionics compartment just for one control panel. By connecting all switches and indicators on a panel to a CAN bus controller, data is only transmitted with two wires.  Integrated Control Panels (ICP) connect to I/O modules using CAN data buses.  I/O modules transmit data to the Avionics Data Communication Netowrk using the highly reliable Avionics Full Duplex Ethernet Bus (AFDX) and it goes to computer LRUs to perform the intended action.  This approach reduces wiring, improves maintenance, and reduces unnecessary aircraft weight.

Implications for UAS

Thanks to the adoption of CAN by the aerospace industry for many years, the technology is finding its way into the UAS industry.  You can now transfer information from the flight controller to the ESC (Electronic Speed Controller) and back from the the ESC to the flight contorller via a serial bus. The flight controller can not only manage the throttle of the ESC, the ESC can report back to the flight controller (reporting the temperature, voltage, amperage, warning signals, etc. via live telemetry.  This provides safe monitoring of all proulsion equipment, allowing the pilot to monitor the full system for safe operation and can be customized through live-programming.

CAN significantly increases the reliability and information sent to the ground. Because the CAN bus protocol is PWM, its more immune to noise than the current method of throttle control used for the industry.  The digital CAN multiplex serial-bus control is currently being implemented in upcoming UAS to allow for direct motor control and live-telemetry feedback to the flight controller.

Canbus in Building Automation

Building automation involves using a control system to monitor and command the mechanical, lighting, security control, and fire alarm systems of a commercial building.  This smart network allows you to keep the building temperature within a specific range, control lighting, monitor system performance, and send out alarm signals to maintenance engineers and administrators should failure occur. Building automation systems include HVAC, lighting, electricity, hot water, fire, access, security/surveillance, vehicle parking , plumbing, lifts, and elevator.

Using CAN for lower layer networks has advantages over RS485 in the field of automation due to its multimaster architecture.  Compared to common bus networks such as Ethernet or networks based on network passing, CAN provides real-time features and ease of implementation at a lower cost.

Here is how implementation of a CAN node connected to Ethernet might look like in successful building automation:

• Lighting Control
  • Motion/Occupancy Sensor - it easily identifies whether a particular room is occupied so that ambiance can be improved.
  • Timer controlling ambiance - After getting output from the sensor a timer is started, the ambiance of the room is improved, and a timer tracks how much time elapses until the ambiance should change

• Fire prevention - this functionality is implemented by setting the fire alarms to go off as soon as there is fire detected using a heat sensor.
• Security - Video and audio monitoring system are used because an operator is not available. A user can be notified through a system to the system or mobile, pager etc. Security cameras can also be used.
• Smoke detection - a smoke alarm when smoke is detected. The valves (plates) are turned off to stop air entering in case of smoke alarm and exhaust is started.
• Temperature control and Air conditioning - a temperature sensor is used to detect the temperature at any point in time and turn ventilation on and off, as well as, air conditioning system.