IT Story, English Diary, Japanese Diary
Showing posts with label スマートカー. Show all posts
Showing posts with label スマートカー. Show all posts
Monday, February 18, 2013
Wednesday, October 31, 2012
Hiriko electric car folds up to take one-third of a parking spot, pilot program to begin next year
This is quoted from http://www.theverge.com/2012/1/25/2733709/hiriko-folding-car-electric-ev-citycar-mit .
We've seen urban cars with a single, windshield-mounted door and we've seen a baby stroller that can fold itself,
but this is the first time we've seen the two combined. It's called the
Hiriko (Basque for "urban"), and a full-sized prototype of the folding
electric car was unveiled in front of the European Union Commission
chief in Brussels yesterday. The tiny vehicle isn't just a Smart car: it
can fold to minimize the amount of space it takes, and three of the
vehicles can fit in a typical parking spot once folded.
Making a car that can fold itself isn't as simple as adding some hinges; the Hiriko has a single, upward-swinging windshield instead of doors and each of the Hiriko's four wheels contain a drive motor, steering, braking, and suspension, leaving the inside of the car uncluttered and free to be collapsed. The wheels also give the car a zero-point turning radius (meaning it can spin in place) and enough speed to drive safely on city streets. It's said that the Hiriko will have a 100 kilometer (about 60 mile) range, and it's target price for individuals is €12,500 (about $16,355).
The Hiriko is the commercial version of MIT Media Lab's CityCar, and the model demonstrated in Brussels represents the first full-sized prototype. Although it's possible that the vehicle will be sold to individuals, it's planned for shared-use projects like the bicycle sharing programs that are popular in many European cities. If you can't wait to see the Hiriko in person, you're probably going to have to head to Vitoria Gasteiz near Bilbao, Spain, where a 20-unit pilot program is scheduled to start up next year. If you can't make it there, you'll be glad to hear that San Francisco, Berlin, Barcelona, Malmö, and Hong Kong have shown interest in the program as well.
Check out a full gallery of photos at the National Post of the Hiriko prototype's unveil, and see below for an MIT clip on the CityCar and a Spanish video from the event in Brussels.
Hiriko electric car folds up to take one-third of a parking spot, pilot program to begin next year
By Dante D'Orazio on
Making a car that can fold itself isn't as simple as adding some hinges; the Hiriko has a single, upward-swinging windshield instead of doors and each of the Hiriko's four wheels contain a drive motor, steering, braking, and suspension, leaving the inside of the car uncluttered and free to be collapsed. The wheels also give the car a zero-point turning radius (meaning it can spin in place) and enough speed to drive safely on city streets. It's said that the Hiriko will have a 100 kilometer (about 60 mile) range, and it's target price for individuals is €12,500 (about $16,355).
The Hiriko is the commercial version of MIT Media Lab's CityCar, and the model demonstrated in Brussels represents the first full-sized prototype. Although it's possible that the vehicle will be sold to individuals, it's planned for shared-use projects like the bicycle sharing programs that are popular in many European cities. If you can't wait to see the Hiriko in person, you're probably going to have to head to Vitoria Gasteiz near Bilbao, Spain, where a 20-unit pilot program is scheduled to start up next year. If you can't make it there, you'll be glad to hear that San Francisco, Berlin, Barcelona, Malmö, and Hong Kong have shown interest in the program as well.
Check out a full gallery of photos at the National Post of the Hiriko prototype's unveil, and see below for an MIT clip on the CityCar and a Spanish video from the event in Brussels.
world's first folding electric car by hiriko motors
This is quoted from http://www.designboom.com/weblog/cat/16/view/23175/worlds-first-folding-electric-car-by-hiriko-motors.html .
world's first folding electric car by hiriko motors
world's first folding electric car by hiriko motors
developed as an innovative solution for means of alternative transportation, the hiriko folding electric vehicle provides new
meaning to urban mobility. the concept automoblile bridges the
relationship between the city and its inhabitants by accommodating
easy and accessible driving solutions within a busy metropolitan area.
in a collaboration between
MIT's changing places, denokinn
basque center for innovation and afypaida, the design caters to an
environment that promotes more social, sustainable and smarter
cities. the small commuter car integrates a 20 horsepower electric
motor,
controlled by a drive-by-wire system, where it achieves a range of 120 km (75 miles) with a top speed of 50 km/h (31 mph).
each wheel contains a separate drive motor, steering, braking, and suspension system, allowing its body to
collapse into two separate units for tight parking spaces.
see designboom's original coverage during the prototyping stages of the model
here.
front view of the hiriko folding electric car
rear view of the hiriko folding electric car
the hiriko electric car collapsing
3/4 rear view of the hiriko folding electric car before collapsing
scale and proporting
Tuesday, October 30, 2012
Intel readies for programmable smart cars
This is quoted from http://www.computerworld.com/s/article/9232781/Intel_readies_for_programmable_smart_cars .
"In the next generation, we are talking about quad-core," said Michael Konow, an Intel engineering manager based in Germany.
"We are looking far ahead to safe driving cars,"
he said. "We would need a lot of compute power for a car to understand
that if there's a ball rolling on the street, there might be a kid
running after it. This is very, very difficult. As humans, we have
intuition. We need to find a way to get this intelligence into the
system."
Konow, who presented a smart car demo at Intel's European Research and Innovation Conference here today, told Computerworld that the auto industry is several years away from having many-core chips in cars, but that lab work on the technology is well underway.
"A car that drives autonomously and has a 100% guarantee that an accident won't happen would require a lot more compute performance," he said. "How much? We don't really know yet."
Today's cars, said Konow and Enno Luebbers, a research scientist at Intel Labs Europe, are getting overloaded with single-core chips. That's a problem, because eventually there won't be enough room for the additional chips that would be necessary to accommodate the ever-growing user demand for new functionality.
Adding a new function requires adding a new chip, said Konow. That means "you [might need] more than a 100 single cores in one high-end car," he said. "You cannot keep up this trend."
With so many single-core chips stuffed into one vehicle, onboard computer systems are becoming too large and complicated, he said.
The goal now is to save power and space, "which is critical because there is basically no space left," added Konow. "[Researchers] are trying to come up with weird shapes of boxes to squeeze them into the tiny amount of space left."
When automakers are able to integrate multi-core chips -- from quad-core to 8-core, 12-core and beyond -- into vehicles, they'll be able to add a lot more functionality, such as updated navigation options, more safety features and social applications.
Today, you have to buy a new car if you want the latest automotive apps. In the future, automakers will offer programmable cars, and users will be able to simply download new apps or upgrades if they want state-of-the-art systems, say Intel execs.
"It's almost like 'What applications wouldn't you want in your car?'" said Intel CTO Justin Rattner. "Once the car is a programmable platform, you'll see all kinds of innovation."
Rattner noted that the smarter cars could work together to make commutes easier.
For instance, cars could have sensors, cameras and computer chips programmed to report potholes to road maintenance crews, and to report traffic jams or accidents to other cars in the area.
In-car apps also could tell drivers which local parking garage has spaces available, or if any of their friends are driving nearby.
"We'll start thinking of our cars more like we think of our laptops and phones -- updateable," said Luebbers.
"For me, it's about synthesis," said Martin Curley, director of Intel Labs Europe. "We're thinking about how these can be integrated into a system of systems that helps us achieve a sustainable society."
Luebbers said a key challenge for engineers working on smarter cars is to ensure safety and security. It's one thing for an entertainment system to be breached; it's another for hackers to access a rearview monitoring system, for instance.
"One of the main challenges is integrating functions of different criticality," he said. "You have to treat the testing and development differently."
A higher level of security will be necessary when we start driving connected cars.
"Over the last 20 or 30 years, [onboard car computers] weren't built with security in mind. It was not required," said Konow. "[Automakers] were looking to save costs. They did not need to design it to be secure."
Widespread connectivity, though, presents the potential for significant problems, he said. "[Automakers] don't want to re-engineer a whole system, but have to find a way to protect systems from external attacks."
Luebbers also noted that car makers have traditionally focused on making sure vehicles did not fail by accident. Now they have to focus on making sure they do not fail because of a digital attack.
That, he said, forces OEMs to think about security in a new way.
Sharon Gaudin covers the Internet and Web 2.0, emerging technologies, and desktop and laptop chips for Computerworld. Follow Sharon on Twitter at
@sgaudin, or subscribe to Sharon's RSS feed 
. Her email address is sgaudin@computerworld.com.
Intel readies for programmable smart cars
Building multi-core chips that could runs apps that drive cars, find parking garages and complain about potholes
October 23, 2012
Computerworld -
BARCELONA -- Intel researchers envision a future of driverless smart
cars that can be updated at any time with the latest technology and
apps.
Intel hopes to play a major role in the new age, creating small, energy-efficient multi-core chips that can make cars more intelligent."In the next generation, we are talking about quad-core," said Michael Konow, an Intel engineering manager based in Germany.
Enno Luebbers, a research scientist at Intel
Labs Europe, shows an Intel-based smart car system. Running a low-power
processor similar to Intel's Atom chip, the system is running car- and
driving-related apps, such as a navigation system, along with an
Android-based entertainment system that has games and movies. (Photo by
Sharon Gaudin/Computerworld)
Konow, who presented a smart car demo at Intel's European Research and Innovation Conference here today, told Computerworld that the auto industry is several years away from having many-core chips in cars, but that lab work on the technology is well underway.
"A car that drives autonomously and has a 100% guarantee that an accident won't happen would require a lot more compute performance," he said. "How much? We don't really know yet."
Today's cars, said Konow and Enno Luebbers, a research scientist at Intel Labs Europe, are getting overloaded with single-core chips. That's a problem, because eventually there won't be enough room for the additional chips that would be necessary to accommodate the ever-growing user demand for new functionality.
Adding a new function requires adding a new chip, said Konow. That means "you [might need] more than a 100 single cores in one high-end car," he said. "You cannot keep up this trend."
With so many single-core chips stuffed into one vehicle, onboard computer systems are becoming too large and complicated, he said.
The goal now is to save power and space, "which is critical because there is basically no space left," added Konow. "[Researchers] are trying to come up with weird shapes of boxes to squeeze them into the tiny amount of space left."
When automakers are able to integrate multi-core chips -- from quad-core to 8-core, 12-core and beyond -- into vehicles, they'll be able to add a lot more functionality, such as updated navigation options, more safety features and social applications.
Today, you have to buy a new car if you want the latest automotive apps. In the future, automakers will offer programmable cars, and users will be able to simply download new apps or upgrades if they want state-of-the-art systems, say Intel execs.
"It's almost like 'What applications wouldn't you want in your car?'" said Intel CTO Justin Rattner. "Once the car is a programmable platform, you'll see all kinds of innovation."
Rattner noted that the smarter cars could work together to make commutes easier.
For instance, cars could have sensors, cameras and computer chips programmed to report potholes to road maintenance crews, and to report traffic jams or accidents to other cars in the area.
In-car apps also could tell drivers which local parking garage has spaces available, or if any of their friends are driving nearby.
"We'll start thinking of our cars more like we think of our laptops and phones -- updateable," said Luebbers.
"For me, it's about synthesis," said Martin Curley, director of Intel Labs Europe. "We're thinking about how these can be integrated into a system of systems that helps us achieve a sustainable society."
Luebbers said a key challenge for engineers working on smarter cars is to ensure safety and security. It's one thing for an entertainment system to be breached; it's another for hackers to access a rearview monitoring system, for instance.
"One of the main challenges is integrating functions of different criticality," he said. "You have to treat the testing and development differently."
A higher level of security will be necessary when we start driving connected cars.
"Over the last 20 or 30 years, [onboard car computers] weren't built with security in mind. It was not required," said Konow. "[Automakers] were looking to save costs. They did not need to design it to be secure."
Widespread connectivity, though, presents the potential for significant problems, he said. "[Automakers] don't want to re-engineer a whole system, but have to find a way to protect systems from external attacks."
Luebbers also noted that car makers have traditionally focused on making sure vehicles did not fail by accident. Now they have to focus on making sure they do not fail because of a digital attack.
That, he said, forces OEMs to think about security in a new way.
Sharon Gaudin covers the Internet and Web 2.0, emerging technologies, and desktop and laptop chips for Computerworld. Follow Sharon on Twitter at
@sgaudin, or subscribe to Sharon's RSS feed . Her email address is sgaudin@computerworld.com.Monday, October 15, 2012
CAN (Controller Area Network): Introduction and Fundamentals
This is quoted from http://microcontroller.com/CAN_%28Controller_Area_Network%29:_Introduction_and_Fundamentals.htm .
CAN (Controller Area Network): Introduction and Fundamentals
- What you will learn here:
- Introduction to CAN
- History
- Data Link Layer
- Physical Layer
- CAN Implementations
CAN (Controller Area Network)
This is quoted from http://hem.bredband.net/stafni/developer/CAN.htm .
CAN can theoretically link up to 2032 devices (assuming one node with one identifier) on a single network. However, due to the practical limitation of the hardware (transceivers), it can only link up to110 nodes (with 82C250, Philips) on a single network. It offers high-speed communication rate up to 1 Mbits/sec thus allows real-time control. In addition, the error confinement and the error detection feature make it more reliable in noise critical environment.
Top of page
Top of page
There are two ISO standards for CAN. The difference is in the physical layer, where ISO 11898 handles high speed applications up to 1Mbit/second. ISO 11519 has an upper limit of 125kbit/second.
Most 2.0A controllers transmit and receive only Standard format messages,
although some (known as 2.0B passive) will receive Extended format messages
but then ignore them. 2.0B controllers can send and receive messages in both
formats. Note that if 29 bit identifiers are used on a bus which contains
part A controllers, the bus will not work!!!
Top of page
Instead, the content of the message is labelled by an identifier that is unique throughout the network. All other nodes on the network receive the message and each performs an acceptance test on the identifier to determine if the message, and thus its content, is relevant to that particular node.
If the message is relevant, it will be processed; otherwise it is ignored.
The higher priority message is guaranteed to gain bus access as if it were the only message being transmitted. Lower priority messages are automatically re-transmitted in the next bus cycle, or in a subsequent bus cycle if there are still other, higher priority messages waiting to be sent.
Each CAN message has an identifier which is 11 bits (CAN specification part A) or 29 bits (part B). This identifier is the principle part of the CAN arbitration field, which is located in the beginning of each CAN message. The identifier identifies the type of message, but is also the message priority.
The bits in a CAN message can be sent as either high or low. The low bits are always dominant, which means that if one node tries to send a low and another node tries to send a high, the result on the buses will be a low. A transmitting node always listens on the bus while transmitting. A node that sends a high in the arbitration field and detects a low knows that it has lost arbitration. It stops transmitting, letting the other node, with a higher priority message, continue uninterrupted.
Two nodes on the network are not allowed to send messages with the same id. If two nodes try to send a message with the same id at the same time arbitration will not work. Instead, one of the transmitting nodes will detect that his message is distorted outside of the arbitration field. The nodes will then use the error handling of CAN, which in this case ultimately will lead to one of the transmitting node being switched off (bus-off mode).
Remote frames can be described as a request for information. A frame with the RTR bit set (see description of the CAN message format) means the transmitting node is asking for information of the type given by the identifier. A node which has the information available should then respond by sending the information onto the network.
Depending on the implementation of the CAN controller the answer may be sent automatically. Simpler CAN controllers (BasicCAN) can not respond automatically. In this case the host microcontroller is made aware of the remote request and has to send the data.
Top of page
The CAN protocol supports two Message Frame formats.
The two formats are:
- Standard CAN (Version 2.0A)
- Extended CAN (Version 2.0B)
Most 2.0A controllers transmit and receive only Standard format messages, although some (known as 2.0B passive) will receive Extended format messages but then ignore them. 2.0B controllers can send and receive messages in both formats.
- A Start of Frame (SOF) field. This is a dominant (logic 0) bit that indicates the beginning of a message frame.
- An Arbitration field, containing an 11 bit message identifier and the Remote Transmission Request (RTR) bit. A dominant (logic 0), RTR bit indicates that the message is a Data Frame. A recessive (logic 1) value indicates that the message is a Remote Transmission Request (otherwise known as Remote Frame.) A Remote Frame is a request by one node for data from some other node on the bus. Remote Frames do not contain a Data Field.
Fig CAN 2.0A Message Frame
- A Control Field containing six bits:
* two dominant bits (r0 and r1) that are reserved for future use, and
* a four bit Data Length Code (DLC). The DLC indicates the number of bytes in the Data Field that follows
- A Data Field, containing from zero to eight bytes.
- The CRC field, containing a fifteen bit cyclic redundancy check code and a recessive delimiter bit
- The ACKnowledge field, consisting of two bits. The first is the Slot bit which is transmitted as a recessive bit, but is subsequently over written by dominant bits transmitted from all other nodes that successfully receive the message. The second bit is a recessive delimiter bit
- The End of Frame field, consisting of seven recessive bits.
Following the end of a frame is the INTermission field consisting of three recessive bits. After the three bit INTermission period the bus is recognised to be free. Bus Idle time may be of any arbitrary length including zero.
Version 2.0B evolved to provide compatibility with other serial communications protocols used in automotive applications in the USA. To cater for this, and still provide compatibility with the 2.0A format, the Message Frame in Version 2.0B has an extended format.
The differences are:
- In Version 2.0B the Arbitration field contains two identifier bit fields. The first (the base ID) is eleven (11) bits long for compatibility with Version 2.0A. The second field (the ID extension) is eighteen (18) bits long, to give a total length of twenty nine (29) bits.
- The distinction between the two formats is made using an Identifier Extension (IDE) bit.
Fig 4.CAN 2.0B Message Frame
- A Substitute Remote Request (SRR) bit is included in the Arbitration Field. The SRR bit is always transmitted as a recessive bit to ensure that, in the case of arbitration between a Standard Data Frame and an Extended Data Frame, the Standard Data Frame will always have priority if both messages have the same base (11 bit) identifier.
All other fields in a 2.0B Message Frame are identical to those in the Standard format.
Note, however, that there are two types of 2.0A controllers:
- The first is capable of transmitting and receiving only messages in 2.0A format. With this type of controller, reception of any 2.0B message will flag an error.
- The second type of 2.0A controller (known as 2.0B passive) is also capable of sending and receiving 2.0A messages, but in addition, these devices will acknowledge receipt of 2.0B messages and then ignore them.
Therefore, within the above mentioned constraints it is possible to use both Version 2.0A (with 2.0B passive capabilities) and 2.0B controllers on a single network.
However, because of the lack of full upward compatibility of 2.0A devices with 2.0B devices, only messages in Standard format are meaningful in systems using both types.
The number of unique identifiers available to users, on a single 2.0A network, is 2,032 (2 to the power 11 - 2 to the power 4).
The number of unique identifiers available on a 2.0B network is in excess of 500 million!
The counters are updated as follows:
The active error flag consists of six low bits, and is used if the node transmitting the error frame is in active error state. As low is dominant all other nodes will detect bit stuffing violation and send their own error flags. After this, nodes that want to transmit (including the one sending the interrupted message) will start to do so. As usual, the node whose message has the highest priority will win arbitration and send its message.
If the CAN controller is in error passive mode the error frame will consist of six passive (high) bits. Since the error flag only consists of passive bits, the bus is not affected. If no other node detected an error, the message will be sent uninterrupted. This ensures that a node having problems with receiving can not block the bus.
All of this advanced error handling is done automatically by the CAN controller, without any need for the host microcontroller to do anything. This is one of the big advantages of CAN.
The choice of bit timing is very important since it decides the bit rate, the sample point and the ability to resynchronise.
A time quantum is a fixed amount of time which is derived from the CAN controller clock with a prescale factor.
This segment is always one time quantum long.
The segment size is programmable between 1 and 8 time quanta.
Normally there is only one sample point for each bit. In this case, the sample point is in the edge between TSEG1 and TSEG2. However, some CAN controllers can also sample each bit three times. In this case, the bit will be sampled three quanta in a row, with the last sample being taken in the edge between TSEG1 and TSEG2.
Three samples should only be used for relatively slow baudrates.
Warning: some CAN controllers (like Intel 526) has an other way of calculating the number of time quantas in a bit! Consult your users manual.
CAN transmits signals on the CAN bus which consists of two wires, a CAN-High and CAN-Low. These 2 wires are operating in differential mode, that is they are carrying inverted voltages (to decrease noise interference) The voltage levels, as well as other characteristics of the physical layer, depend on which standard is being used.
Note that for the recessive state, nominal voltage for the two wires is
the same. This decreases the power drawn from the nodes through the
termination resistors. These resistors are 120ohm and are located on each
end of the wires. Some people have played with using central termination
resistors (that is, putting them in one place on the bus). This is not
recommended, since that configuration will not prevent reflection problems.
ISO 115519 does not require termination resistors. They are not necessary
because the limited bit rates (maximum 125 kB/s) makes the bus insensitive
to reflections.
The voltage level on the CAN bus is recessive when the bus is idle.
Below is a table of different bus lengths and the corresponding maximum bit rates.
on the single-wire standard SAE J2411.
Top of page
The main difference between these strategies is how interesting messages are filtered out, that is how it is decided what messages are interesting and which are not. There are also differences in how remote frames are answered, and on how messages are buffered. The differences will effect how much load is put on the host microcontroller.
A BasicCAN controller normally has two receive buffers and one transmit buffer. The receive buffers are arranged in a FIFO structure, and a message can be received into the one buffer while the microcontroller is reading the information from the other buffer. If a message is received while both receive buffers are full, the oldest messages are kept. This means that newer messages might be lost if the host microcontroller does not read the messages fast enough.
A message is sent by writing it to the transmit buffer.
Interesting messages are filtered out using two registers, that operate on the message identifier. Each bit in the identifier are checked against the filter. If the message matches the filter it is stored in one of the receive buffers.
Each bit of the identifier filter can be set to '1', '0' or 'don't care'. Often the filter only operates on eight of the eleven bits in the identifier (standard CAN). This means the three lower bits in the identifier are always 'don't care'.
When BasicCAN is used it is important to choose identifiers with utmost care, so that the window of the filter can be kept as small as possible. All message that is let through the filter must be read and checked by the microcontroller. This means that the final filtering is done in software.
A BasicCAN controller has no support for automatically answering remote frames, which means that the application will have to handle them. This will put extra load on the microcontroller or processor, but will make sure that the value returned is updated.
When the CAN controller receives a message it checks the mailboxes in order to see is there is a receive mailbox with the same identifier as the message. If such a mailbox is found, the message is stored in it and the host controller is notified. Otherwise the message is discarded.
When transmitting a message the message length and data is written to the transmit mailbox with the correct identifier.
If a remote message is received the controller checks the remote identifier against the transmit mailboxes. If a match is found, the controller automatically sends a message with the identifier and data contained in that mailbox. This means that the microcontroller gets a lower load, and that the software does not have to handle remote messages. However, if the mailbox has not been updated in a long time, the information sent to the network will be old. This have to be considered when writing the software.
With a FullCAN controller it is possible to filter out only the exact message types that are interesting. This type of controller will therefore give a lower load on the host microcontroller. However, the number of mailboxes are limited. The largest number of mailboxes present in a CAN controller today is ???.
With some controllers it is possible to reconfigure the mailboxes dynamically. However, that does not completely solve the problem. Therefore some controllers are mixed CAN controllers, that is they have mailboxes, but also BasicCAN buffers.
FullCAN controllers have support for automatically answering remote frames. This will decrease the load on the host microcontroller or processor, but may also mean that old information is sent. It is very important to take this into consideration when writing your application.
Top of page
Question: The transmitter considers the data / remote frame transfer valid if no error occurs until the end of the corresponding EOF delimiter.
Why does the receiver consider the transfer valid when there is no error until the last but one bit of the EOF delimiter ( why doesn't the receiver check until the end of the corresponding EOF delimiter, like what the transmitter do. ) ?
Answer: If a receiver detects a corrupt frame, it sends an error frame (in the normal case, an active error flag). This will cause all other receivers AND the transmitter to detect a corrupt frame, they all send their error frames and the transmitter resends the frame (normal arbitration is used).
Now assume that the protocol was implemented the way that you suggest, what would happen if the receiver detects an error on the last bit of the EOF? It will start to send its error frame, but the transmitter (and other receivers) may already have have accepted the frame as valid (not having detected any errors up to and including the whole eof). This means that one (or more) receivers have not received a valid frame, but the transmitter thinks that it is sent ok and will not repeat it!!!
The problem is solved in CAN - if a receiver detects an error in the last bit that it cares about (the last but one bit of the eof) it will send an error frame. This will corrupt the last bit that the transmitter cares about (the last bit of the eof) and he will retransmit the message.
Question: Why is the number of unique identifiers available to users, on a single 2.0A network, 2,032 (2 to the power 11 - 2 to the power 4)? What happens to the other 16 identifiers?
Answer: Some old CAN controllers (notably the Intel 82526) could not handle messages where the 7 most significant bits where all set to one. That leaves identifiers 0..2031 for use. If you know that no such old CAN controllers will be connected to the bus, all of the 2048 possible identifiers may be used.
Controller Area Network - CAN Information
Contents
here.What is CAN?
Controller Area Network (CAN) is a serial network that was originally designed for the automotive industry, but has also become a popular bus in industrial automation as well as other applications. The CAN bus is primarily used in embedded systems, and as its name implies, is the network established among microcontrollers. It is a two-wire, half duplex, high-speed network system and is well suited for high speed applications using short messages. Its robustness, reliability and the large following from the semiconductor industry are some of the benefits with CAN.CAN can theoretically link up to 2032 devices (assuming one node with one identifier) on a single network. However, due to the practical limitation of the hardware (transceivers), it can only link up to110 nodes (with 82C250, Philips) on a single network. It offers high-speed communication rate up to 1 Mbits/sec thus allows real-time control. In addition, the error confinement and the error detection feature make it more reliable in noise critical environment.
Top of page
History
CAN was first developed by Robert Bosch GmbH, Germany in 1986 when they were requested to develop a communication system between three ECUs (electronic control units) in vehicles by Mercedes. They found that an UART is no longer suitable in this situation because it is used in point-to-point communication. The need for a multi-master communication system became imperative. The first CAN silicon was then fabricated in 1987 by IntelTop of page
CAN standards
The original specification is the Bosch specification. Version 2.0 of this specification is divided into two parts:- Standard CAN (Version 2.0A). Uses 11 bit identifiers.
- Extended CAN (Version 2.0B). Uses 29 bit identifiers.
There are two ISO standards for CAN. The difference is in the physical layer, where ISO 11898 handles high speed applications up to 1Mbit/second. ISO 11519 has an upper limit of 125kbit/second.
Part A and Part B compatibility
There are three types of CAN controllers: Part A, Part B passive and Part B. They are able to handle the different parts of the standard as follows:| Message format \ CAN chip type | Part A | Part B Passive | Part B |
| 11 bit ID | ok | ok | ok |
| 29 bit ID | ERROR!! | tolerated on the bus, but ignored | ok |
Top of page
How does CAN work?
Introduction
As stated earlier, CAN is a multi master network. It uses CSMA/CD+AMP (Carrier Sense Multiple Access/Collision Detection with Arbitration on Message Priority). Before sending a message the CAN node checks if the bus is busy. It also uses collision detection. In these ways it is similar to Ethernet. However, when an Ethernet network detects collision both sending nodes stop transmitting. They then wait a random time before trying to send again. This make Ethernet networks very sensitive to high bus loads. CAN solves this problem with the very clever principle of arbitration.Principle
Data messages transmitted from any node on a CAN bus do not contain addresses of either the transmitting node, or of any intended receiving node.Instead, the content of the message is labelled by an identifier that is unique throughout the network. All other nodes on the network receive the message and each performs an acceptance test on the identifier to determine if the message, and thus its content, is relevant to that particular node.
If the message is relevant, it will be processed; otherwise it is ignored.
Identifiers & arbitration
The unique identifier also determines the priority of the message. The lower the numerical value of the identifier, the higher the priority. This allows arbitration if two (or more) nodes compete for access to the bus at the same time.The higher priority message is guaranteed to gain bus access as if it were the only message being transmitted. Lower priority messages are automatically re-transmitted in the next bus cycle, or in a subsequent bus cycle if there are still other, higher priority messages waiting to be sent.
Each CAN message has an identifier which is 11 bits (CAN specification part A) or 29 bits (part B). This identifier is the principle part of the CAN arbitration field, which is located in the beginning of each CAN message. The identifier identifies the type of message, but is also the message priority.
The bits in a CAN message can be sent as either high or low. The low bits are always dominant, which means that if one node tries to send a low and another node tries to send a high, the result on the buses will be a low. A transmitting node always listens on the bus while transmitting. A node that sends a high in the arbitration field and detects a low knows that it has lost arbitration. It stops transmitting, letting the other node, with a higher priority message, continue uninterrupted.
Two nodes on the network are not allowed to send messages with the same id. If two nodes try to send a message with the same id at the same time arbitration will not work. Instead, one of the transmitting nodes will detect that his message is distorted outside of the arbitration field. The nodes will then use the error handling of CAN, which in this case ultimately will lead to one of the transmitting node being switched off (bus-off mode).
Remote frames
There are two kinds of frames in CAN - remote frames and data frames. Data frames are used when a node wants to transmit data on the network, and are the "normal" frame type.Remote frames can be described as a request for information. A frame with the RTR bit set (see description of the CAN message format) means the transmitting node is asking for information of the type given by the identifier. A node which has the information available should then respond by sending the information onto the network.
Depending on the implementation of the CAN controller the answer may be sent automatically. Simpler CAN controllers (BasicCAN) can not respond automatically. In this case the host microcontroller is made aware of the remote request and has to send the data.
Top of page
Message formats
Format of a CAN message
In a CAN system, data is transmitted and received using Message Frames. Message Frames carry data from a transmitting node to one, or more, receiving nodes.The CAN protocol supports two Message Frame formats.
The two formats are:
- Standard CAN (Version 2.0A)
- Extended CAN (Version 2.0B)
Most 2.0A controllers transmit and receive only Standard format messages, although some (known as 2.0B passive) will receive Extended format messages but then ignore them. 2.0B controllers can send and receive messages in both formats.
2.0A Format
A Standard CAN (Version 2.0A) Message Frame consists of seven different bit fields:- A Start of Frame (SOF) field. This is a dominant (logic 0) bit that indicates the beginning of a message frame.
- An Arbitration field, containing an 11 bit message identifier and the Remote Transmission Request (RTR) bit. A dominant (logic 0), RTR bit indicates that the message is a Data Frame. A recessive (logic 1) value indicates that the message is a Remote Transmission Request (otherwise known as Remote Frame.) A Remote Frame is a request by one node for data from some other node on the bus. Remote Frames do not contain a Data Field.
Fig CAN 2.0A Message Frame
- A Control Field containing six bits:
* two dominant bits (r0 and r1) that are reserved for future use, and
* a four bit Data Length Code (DLC). The DLC indicates the number of bytes in the Data Field that follows
- A Data Field, containing from zero to eight bytes.
- The CRC field, containing a fifteen bit cyclic redundancy check code and a recessive delimiter bit
- The ACKnowledge field, consisting of two bits. The first is the Slot bit which is transmitted as a recessive bit, but is subsequently over written by dominant bits transmitted from all other nodes that successfully receive the message. The second bit is a recessive delimiter bit
- The End of Frame field, consisting of seven recessive bits.
Following the end of a frame is the INTermission field consisting of three recessive bits. After the three bit INTermission period the bus is recognised to be free. Bus Idle time may be of any arbitrary length including zero.
2.0B Format
The CAN 2.0B format provides a twenty nine (29) bit identifier as opposed to the 11 bit identifier in 2.0A.Version 2.0B evolved to provide compatibility with other serial communications protocols used in automotive applications in the USA. To cater for this, and still provide compatibility with the 2.0A format, the Message Frame in Version 2.0B has an extended format.
The differences are:
- In Version 2.0B the Arbitration field contains two identifier bit fields. The first (the base ID) is eleven (11) bits long for compatibility with Version 2.0A. The second field (the ID extension) is eighteen (18) bits long, to give a total length of twenty nine (29) bits.
- The distinction between the two formats is made using an Identifier Extension (IDE) bit.
Fig 4.CAN 2.0B Message Frame
- A Substitute Remote Request (SRR) bit is included in the Arbitration Field. The SRR bit is always transmitted as a recessive bit to ensure that, in the case of arbitration between a Standard Data Frame and an Extended Data Frame, the Standard Data Frame will always have priority if both messages have the same base (11 bit) identifier.
All other fields in a 2.0B Message Frame are identical to those in the Standard format.
2.0A and 2.0B Compatibility
2.0B controllers are completely backward compatible with 2.0A controllers and can transmit and receive messages in either format.Note, however, that there are two types of 2.0A controllers:
- The first is capable of transmitting and receiving only messages in 2.0A format. With this type of controller, reception of any 2.0B message will flag an error.
- The second type of 2.0A controller (known as 2.0B passive) is also capable of sending and receiving 2.0A messages, but in addition, these devices will acknowledge receipt of 2.0B messages and then ignore them.
Therefore, within the above mentioned constraints it is possible to use both Version 2.0A (with 2.0B passive capabilities) and 2.0B controllers on a single network.
However, because of the lack of full upward compatibility of 2.0A devices with 2.0B devices, only messages in Standard format are meaningful in systems using both types.
The number of unique identifiers available to users, on a single 2.0A network, is 2,032 (2 to the power 11 - 2 to the power 4).
The number of unique identifiers available on a 2.0B network is in excess of 500 million!
Error detection and fault confinement
The error detection, signalling and fault confinement defined in the CAN standard makes the CAN bus very reliable. The built in error detection of the controllers together with the error signalling make sure that the information is correct and consistent. Faulty nodes will go to modes where they do not disturb the traffic on the bus.The CAN error process
- The error is detected by the a CAN controller (a transmitter or a receiver).
- An error frame is immediately transmitted.
- The message is cancelled at all nodes (exceptions exist - see CAN controller error modes).
- The status of the CAN controllers are updated (see CAN controller error modes).
- The message is re-transmitted. If several controllers have messages to send, normal arbitration is used.
Error detection
Error detection is handled automatically by the CAN controller. The detected errors are:- Bit errors:
- Bit stuffing error - normally a transmitting node inserts a high after five consecutive low bits(and a low after five consecutive high). This is called bit stuffing. A receiving node that detects violation (more than five consecutive bits will see a bit stuffing violation.
- Bit error: A transmitting node always reads back the message as it is sending. If it detects a different bit value on the bus than it sent, and the bit is not part of the arbitration field or in the acknowledgement field, and error is detected.
- Message errors:
- Checksum error - each receiving node checks CAN messages for checksum errors.
- Frame error - There are certain predefined bit values that must be transmitted at certain points within any CAN Message Frame. If a receiver detects an invalid bit in one of these positions a Form Error (sometimes also known as a Format Error) will be flagged.
- Acknowledgement Error - If a transmitter determines that a message has not been ACKnowledged then an ACK Error is flagged.
CAN controller error modes
A CAN controller can be in one of three states:- Error active - the normal operating mode for a controller. Messages can be received and transmitted. On detecting an error an active error flag is sent (see error signalling).
- Error passive - a mode entered when the controller has frequent problems transmitting or receiving messages. Messages can be received and transmitted. On detecting an error while receiving, a passive error flag is sent.
- Bus off - entered if the controller has serious problems with transmitting messages. No messages can be received or transmitted until the CAN controller is reset by the host microcontroller or processor.
- The CAN controller is in error active mode if tx_count <= 127 AND rx_count <= 127.
- Passive mode is used if (tx_count > 127 OR rx_count > 127) AND tx_count <= 255.
- Bus off is entered if tx_count > 255.
The counters are updated as follows:
- When a receiver detects an error, the rx_count will be increased by 1, except when the detected error was a bit error during the sending of an active error flag or an overload flag.
- When a receiver detects a dominant bit as the first bit after sending an error flag, the rx_count will be increased by 8.
- When a transmitter sends an error flag, the tx_count is increased by
8.
Exception 1:If the transmitter is error passive and detects an ack error because of not detecting a dominant ack and does not detect a dominant bit while sending its passive error flag.
Exception 2: If the transmitter sends an error flag because a stuff error occurred during arbitration whereby the stuff bit is located before the RTR bit, and should have been recessive, and has been sent as recessive but monitored as dominant.
- If a transmitter detects a bit error while sending an active error flag or an overload flag, the tx_count is increased by 8.
- If a receiver detects a bit error while sending an active error flag or an overload flag the rx_count is increased by 8.
- Any node accepts up to 7 consecutive dominant bits after sending an active or passive error flag or an overload flag. After detecting the 14th consecutive dominant bit (in the case of an active error flag or an overload flag), or after detecting the 8th consecutive dominant bit following a passive error flag, and after each sequence of additional 8 consecutive dominant bits every transmitter increases its tx_count by 8 and every receiver increases its rx_count by 8.
- After the successful transmission of a message (getting ack and no error until end of frame is finished) tx_count is decreased by 1 unless it was already 0.
- After the successful reception of a message (reception withour error up to the ack slot and the successful sending of the ack bit), rx_count is decreased by 1 if it was between 1 and 127. If rx_count was 0 it stays 0, and if it was greater than 127, it will be set to a value between 119 and 127.
Error signalling
When an error is detected by a node it sends an error flag on the bus. This prevents any other node from accepting the message and ensures consistency of data throughout the network.The active error flag consists of six low bits, and is used if the node transmitting the error frame is in active error state. As low is dominant all other nodes will detect bit stuffing violation and send their own error flags. After this, nodes that want to transmit (including the one sending the interrupted message) will start to do so. As usual, the node whose message has the highest priority will win arbitration and send its message.
If the CAN controller is in error passive mode the error frame will consist of six passive (high) bits. Since the error flag only consists of passive bits, the bus is not affected. If no other node detected an error, the message will be sent uninterrupted. This ensures that a node having problems with receiving can not block the bus.
All of this advanced error handling is done automatically by the CAN controller, without any need for the host microcontroller to do anything. This is one of the big advantages of CAN.
Bit timing
CAN has advanced features for coping with the time delays found in long bus lengths (in comparison to the bit rate) and coping with differences in clock chrystal frequencies for nodes on the bus.The choice of bit timing is very important since it decides the bit rate, the sample point and the ability to resynchronise.
Bit segments (as in Bosch standard)
Each bit is divided into four segments - the synchronisation segment, the propagation segment and the phase segments one and two. Each segment consists of one or more time quanta.A time quantum is a fixed amount of time which is derived from the CAN controller clock with a prescale factor.
Synchronisation segment (Synch_Seg)
The synchronisation segment is used to synchronise the various nodes on the bus. When a bit is sent on the bus, the leading edge is expected to be within this segment.This segment is always one time quantum long.
Propagation segment (Prop_Seg)
The Propagation Segment is needed to compensate for the delay in the bus lines.The segment size is programmable between 1 and 8 time quanta.
Phase Segment 1 (Phase_Seg1), Phase Segment 2 (Phase_Seg2)
These segments can be used lengthened or shortened by resynchronisation.Bit segments (as in implementations like Intel 527 and C167CR)
In most implementations of CAN controllers the segments seem to be implemented in a different way than described in the standard. The synch segment looks as in the standard and consists of one time quantum. The big difference is that the propagation segment and the phase segment 1 in the standard have been combined into one segment, TSEG1. Phase segment 2 is left untouched, but is renamed to TSEG2.Normally there is only one sample point for each bit. In this case, the sample point is in the edge between TSEG1 and TSEG2. However, some CAN controllers can also sample each bit three times. In this case, the bit will be sampled three quanta in a row, with the last sample being taken in the edge between TSEG1 and TSEG2.
Three samples should only be used for relatively slow baudrates.
Calculation of baudrate and sample point
Baudrate
The baudrate of the bus can be calculated from:
Baudrate = fcrystal / (2*n*(BRP+1))
where n is the number of time quanta for one bit and is defined as :
n = SYNCHSEG+TSEG1+TSEG2
BRP is the value of the BaudRate Prescaler.Warning: some CAN controllers (like Intel 526) has an other way of calculating the number of time quantas in a bit! Consult your users manual.
Sample point
Quantabeforesample = TSEG1 + 1
Quantaaftersample = TSEG2
Often the sample point is given in percent of the bit time. This is:(TSEG1+1)/(TSEG1+1+TSEG2)
Warning: some CAN controllers (like the C167CR) use an other way of
calculating Quantaaftersample. Consult your manual!Resynchronisation
Resynchronisation is done to compensate for bus delays and nodes that have different crystal frequencies. Synchronisation is normally only done on the edge from recessive to dominant bus level.Hard resynchronisation
When the bus is idle and the controller detects a start bit, it resynchronises itself so that the edge is inside the Synch segment. Hard resynchronisation can only be made for the first bit in a frame.Resynchronisation within a frame
CAN controllers have the ability to synchronise on bit edges also within a frame. The (re)Synchronisation Jump Width (SJW) decides the maximum number of time quanta that the controller can resynchronise every bit.- Resynchronisation of a receiver to a slower transmitter is handled as follows:
If a recessive-to-dominant edge appears inside TSEG1 and the edge is less than or equal to SJW quanta inside, TSEG1 is restarted . If the edge was more than SJW quanta inside, TSEG1 is lengthened with SJW quanta.
- Resynchronisation of a receiver to a faster transmitter:
If a recessive-to-dominant edge appears inside TSEG2 , TSEG2 is shortened by the number of quantas necessary to make the edge be outside TSEG2. However, TSEG2 can be shortened no more than SJW quanta.
CAN bus physical layer
The physical layer is not part of the Bosch CAN standard. However, in the ISO standards transceiver characteristics is included.CAN transmits signals on the CAN bus which consists of two wires, a CAN-High and CAN-Low. These 2 wires are operating in differential mode, that is they are carrying inverted voltages (to decrease noise interference) The voltage levels, as well as other characteristics of the physical layer, depend on which standard is being used.
ISO 11898
The voltage levels for a CAN network which follows the ISO 11898 (CAN High Speed) standard are described in the picture and table below.| Signal | recessive state | dominant state | unit | ||||
| min | nominal | max | min | nominal | max | ||
| CAN-High | 2.0 | 2.5 | 3.0 | 2.75 | 3.5 | 4.5 | Volt |
| CAN-Low | 2.0 | 2.5 | 3.0 | 0.5 | 1.5 | 2.25 | Volt |
ISO 11519
The voltage levels for a CAN network which follows the ISO 11519 (CAN Low Speed) standard are described in the table below.| Signal | recessive state | dominant state | unit | ||||
| min | nominal | max | min | nominal | max | ||
| CAN-High | 1.6 | 1.75 | 1.9 | 3.85 | 4.0 | 5.0 | Volt |
| CAN-Low | 3.1 | 3.25 | 3.4 | 0 | 1.0 | 1.15 | Volt |
The voltage level on the CAN bus is recessive when the bus is idle.
Bus lengths
The maximum bus length for a CAN network depends on the bit rate used. It is required that the wave front of the bit signal has time to travel to the most remote node and back again before the bit is sampled. This means that if the bus length is near the maximum for the bit rate used, one should choose the sampling point with utmost care - one the other hand, one should always do that!Below is a table of different bus lengths and the corresponding maximum bit rates.
| Bus length (metres) | Maximum bit rate (bit/s) |
| 40 | 1 Mbit/s |
| 100 | 500 kbit/s |
| 200 | 250 kpit/s |
| 500 | 125 kbit/s |
| 6 km | 10 kbit/s |
Cable
According to the ISO 11898 standard, the impedance of the cable shall be 120 +- 12 ohms. It should be twisted par, shielded or unshielded. Work is in progresson the single-wire standard SAE J2411.
Top of page
CAN implementations
Different implementations - BasicCAN and FullCAN
There is no standard for how CAN controllers shall be implemented or how they shall communicate with their host microcontroller. There are two main implementation strategies for CAN controllers today. They are called BasicCAN and FullCAN.The main difference between these strategies is how interesting messages are filtered out, that is how it is decided what messages are interesting and which are not. There are also differences in how remote frames are answered, and on how messages are buffered. The differences will effect how much load is put on the host microcontroller.
BasicCAN
BasicCAN is usually used in cheaper standalone CAN controllers or in smaller microcontrollers with integrated CAN controller.A BasicCAN controller normally has two receive buffers and one transmit buffer. The receive buffers are arranged in a FIFO structure, and a message can be received into the one buffer while the microcontroller is reading the information from the other buffer. If a message is received while both receive buffers are full, the oldest messages are kept. This means that newer messages might be lost if the host microcontroller does not read the messages fast enough.
A message is sent by writing it to the transmit buffer.
Interesting messages are filtered out using two registers, that operate on the message identifier. Each bit in the identifier are checked against the filter. If the message matches the filter it is stored in one of the receive buffers.
Each bit of the identifier filter can be set to '1', '0' or 'don't care'. Often the filter only operates on eight of the eleven bits in the identifier (standard CAN). This means the three lower bits in the identifier are always 'don't care'.
When BasicCAN is used it is important to choose identifiers with utmost care, so that the window of the filter can be kept as small as possible. All message that is let through the filter must be read and checked by the microcontroller. This means that the final filtering is done in software.
A BasicCAN controller has no support for automatically answering remote frames, which means that the application will have to handle them. This will put extra load on the microcontroller or processor, but will make sure that the value returned is updated.
BasicCAN features
| Transmit | The application fills complete Tx register including ID,RTR,datalength,data -> every ID can be transmitted |
| Receive | Every CAN message can be received Normally two receive buffers in FIFO structure Global message filtering. It is normally not possible to set up the filter so that only the interesting messages are let through -> final filtering must be done by the application |
| Remote frame handling | Remote frame are answered by the application |
| Overrun philosophy | Keep the oldest message (newer messages will be lost) |
FullCAN
FullCAN is used in more expensive, high performance CAN controllers and microcontrollers. The FullCAN controller has a set of buffers called mailboxes. On initialization, each mailbox is assigned an identifier and is set to transmit or receive.When the CAN controller receives a message it checks the mailboxes in order to see is there is a receive mailbox with the same identifier as the message. If such a mailbox is found, the message is stored in it and the host controller is notified. Otherwise the message is discarded.
When transmitting a message the message length and data is written to the transmit mailbox with the correct identifier.
If a remote message is received the controller checks the remote identifier against the transmit mailboxes. If a match is found, the controller automatically sends a message with the identifier and data contained in that mailbox. This means that the microcontroller gets a lower load, and that the software does not have to handle remote messages. However, if the mailbox has not been updated in a long time, the information sent to the network will be old. This have to be considered when writing the software.
With a FullCAN controller it is possible to filter out only the exact message types that are interesting. This type of controller will therefore give a lower load on the host microcontroller. However, the number of mailboxes are limited. The largest number of mailboxes present in a CAN controller today is ???.
With some controllers it is possible to reconfigure the mailboxes dynamically. However, that does not completely solve the problem. Therefore some controllers are mixed CAN controllers, that is they have mailboxes, but also BasicCAN buffers.
FullCAN controllers have support for automatically answering remote frames. This will decrease the load on the host microcontroller or processor, but may also mean that old information is sent. It is very important to take this into consideration when writing your application.
FullCAN features
| Transmit | Transmit mailboxes initialised once Only data bytes written before transmission |
| Receive | Only messages with the IDs defined in receive mailboxes can be
received No double buffering for mailboxes Full acceptance filtering (only the exact message IDs are let through) |
| Remote frame handling | Remote frames are answered automatically by the controller |
| Overrun philosophy | Keep the newest message (older messages with the same ID will be lost) |
FAQ - Frequently Asked Questions
I will update this section as I receive questions from the readers of this page.Question: The transmitter considers the data / remote frame transfer valid if no error occurs until the end of the corresponding EOF delimiter.
Why does the receiver consider the transfer valid when there is no error until the last but one bit of the EOF delimiter ( why doesn't the receiver check until the end of the corresponding EOF delimiter, like what the transmitter do. ) ?
Answer: If a receiver detects a corrupt frame, it sends an error frame (in the normal case, an active error flag). This will cause all other receivers AND the transmitter to detect a corrupt frame, they all send their error frames and the transmitter resends the frame (normal arbitration is used).
Now assume that the protocol was implemented the way that you suggest, what would happen if the receiver detects an error on the last bit of the EOF? It will start to send its error frame, but the transmitter (and other receivers) may already have have accepted the frame as valid (not having detected any errors up to and including the whole eof). This means that one (or more) receivers have not received a valid frame, but the transmitter thinks that it is sent ok and will not repeat it!!!
The problem is solved in CAN - if a receiver detects an error in the last bit that it cares about (the last but one bit of the eof) it will send an error frame. This will corrupt the last bit that the transmitter cares about (the last bit of the eof) and he will retransmit the message.
Question: Why is the number of unique identifiers available to users, on a single 2.0A network, 2,032 (2 to the power 11 - 2 to the power 4)? What happens to the other 16 identifiers?
Answer: Some old CAN controllers (notably the Intel 82526) could not handle messages where the 7 most significant bits where all set to one. That leaves identifiers 0..2031 for use. If you know that no such old CAN controllers will be connected to the bus, all of the 2048 possible identifiers may be used.
Monday, September 10, 2012
Connected Cars Could Become Security Threat
This is quoted from http://cmvlive.com/technology/connected-cars-security-threat .
The benefits of advanced computing technology are legion, but many of
those myriad benefits come with serious security caveats. With the
advent of the computer came the advent of the computer virus.
The Internet ushered in a new digital age that included among its
emergent features several pandemic worms and the specter of cyber
warfare. The threats are real and the potential damages so severe that
almost every susceptible machine now comes equipped with some kind of
anti-virus or digital security software.
As technology becomes integrated in more and more devices, experts have seen the rise of malware designed to threaten atypical targets. Videogame consoles, web TVs, MP3 players and home security systems are only some of the many web-connected devices that have been infiltrated by innovative hackers with novel code. Experts in the automotive field are now concerned that the same kind of malicious software could be developed to target computing software in smart cars.
Cars, like all other pieces of technology, have been changed forever by the digital revolution. Instead of electrical systems, most contemporary vehicles rely on complex computing systems called ECUs. These ECUs depend on millions of lines of code to operate everything from your navigation system to your engine and brakes. These complex computing systems, experts say, are exactly the kind of interconnected systems that are most susceptible to cyber attacks.
Wireless technologies integrated in many new vehicle models are especially vulnerable to remote hacking. Experts speculate that these attacks could cause a range of harm, having effects as innocuous as baffling a climate control system to causing catastrophic damage to an engine or other essential part.
McAfee is a computing company that operates under the Intel umbrella. They’re responsible for the security software that most often treats infected PCs. The people at McAfee have begun research on vehicle cyber security out of a facility in Beaverton, Oregon. Senior McAfee executive Bruce Snell confirmed to the press that automakers are just becoming aware of their vehicles’ digital vulnerabilities. His company issued a recent report on automotive systems security titled, “Caution: Malware Ahead.” The report forecasts dire consequences if automakers don’t make an effort to stay one step ahead of hackers.
Two teams of researchers working out of the University of Washington and the University of California-San Diego have already developed malicious code that targets modern vehicles. The experts working out of those two schools managed to infiltrate a car’s navigation system from a remote laptop. Another research team at the University of South Carolina and Rutgers University in New Jersey demonstrated the ease with which a competent hacker could stage a cyber attack on a vehicle by compromising the RFID tags in tires.
None of the studies were vendor specific. The experts at McAfee caution that this problem is relevant to every manufacturer in the industry. It would be counterproductive, they argue, to single out a single company for failure to protect their vehicles’ computing systems. Everyone, apparently, needs to do more.
If this problem bears fruit in the coming years, drivers may see a spike in car insurance rates to cover the risk of damage from cyber attacks. If you’re interested in how much it would cost you to switch to a higher tech vehicle, get a free auto insurance quote online.
Connected Cars Could Become Security Threat
Published On: Wed, Aug 22nd, 2012
Technology | By CarolMontrose
iPad as a Carputer (Photo credit: Yutaka Tsutano)
As technology becomes integrated in more and more devices, experts have seen the rise of malware designed to threaten atypical targets. Videogame consoles, web TVs, MP3 players and home security systems are only some of the many web-connected devices that have been infiltrated by innovative hackers with novel code. Experts in the automotive field are now concerned that the same kind of malicious software could be developed to target computing software in smart cars.
Cars, like all other pieces of technology, have been changed forever by the digital revolution. Instead of electrical systems, most contemporary vehicles rely on complex computing systems called ECUs. These ECUs depend on millions of lines of code to operate everything from your navigation system to your engine and brakes. These complex computing systems, experts say, are exactly the kind of interconnected systems that are most susceptible to cyber attacks.
Wireless technologies integrated in many new vehicle models are especially vulnerable to remote hacking. Experts speculate that these attacks could cause a range of harm, having effects as innocuous as baffling a climate control system to causing catastrophic damage to an engine or other essential part.
McAfee is a computing company that operates under the Intel umbrella. They’re responsible for the security software that most often treats infected PCs. The people at McAfee have begun research on vehicle cyber security out of a facility in Beaverton, Oregon. Senior McAfee executive Bruce Snell confirmed to the press that automakers are just becoming aware of their vehicles’ digital vulnerabilities. His company issued a recent report on automotive systems security titled, “Caution: Malware Ahead.” The report forecasts dire consequences if automakers don’t make an effort to stay one step ahead of hackers.
Two teams of researchers working out of the University of Washington and the University of California-San Diego have already developed malicious code that targets modern vehicles. The experts working out of those two schools managed to infiltrate a car’s navigation system from a remote laptop. Another research team at the University of South Carolina and Rutgers University in New Jersey demonstrated the ease with which a competent hacker could stage a cyber attack on a vehicle by compromising the RFID tags in tires.
None of the studies were vendor specific. The experts at McAfee caution that this problem is relevant to every manufacturer in the industry. It would be counterproductive, they argue, to single out a single company for failure to protect their vehicles’ computing systems. Everyone, apparently, needs to do more.
If this problem bears fruit in the coming years, drivers may see a spike in car insurance rates to cover the risk of damage from cyber attacks. If you’re interested in how much it would cost you to switch to a higher tech vehicle, get a free auto insurance quote online.
Sunday, May 20, 2012
Is Microsoft Windows Embedded Automotive open source? What operating systems does Microsoft Windows Embedded Automotive support? What APIs and programming languages does Microsoft Windows Embedded Automotive support for application development?
Is Microsoft Windows Embedded Automotive open source?
What operating systems does Microsoft Windows Embedded Automotive support?
What APIs and programming languages does Microsoft Windows Embedded Automotive support for application development?
What operating systems does Microsoft Windows Embedded Automotive support?
What APIs and programming languages does Microsoft Windows Embedded Automotive support for application development?
Friday, May 18, 2012
Is MirrorLink open source? What operating systems does MirrorLink support? What APIs and programming languages does MirrorLink support for application development?
Is MirrorLink open source?
What operating systems does MirrorLink support?
What APIs and programming languages does MirrorLink support for application development?
What operating systems does MirrorLink support?
What APIs and programming languages does MirrorLink support for application development?
Friday, April 27, 2012
Thursday, April 5, 2012
Tuesday, March 6, 2012
Sunday, March 4, 2012
Saturday, March 3, 2012
LTE Connected Car - The Concept, The Participants
This is quoted from http://www.ngconnect.org/program/connected-car.htm .
Soon the must-have option for new cars
won't be a sunroof or leather seats—it will be ultra high-speed,
high-bandwidth connectivity that revolutionizes the in-vehicle
experience for drivers and passengers. Within the LTE Connected Car,
consumers will be able to access network- and cloud-based applications
that put on-demand entertainment, infotainment, diagnostics, navigation
and much more at their fingertips.
It all started with a simple question. What happens if you connect a car to an ultra high-speed mobile network? Several innovative companies in very different industries were asking this same question. And when the ng Connect Program brought them together, the LTE Connected Car Service Concept was born.
And consumers are very interested! A recent Market Advantage study* of American and European consumers indicated that they are willing to pay for these innovative social, entertainment and business applications - if they are easy to use and offer a high quality of service. Navigation reigns as most the desired feature overall with Enhanced GPS and Maintenance Tracking consistently preferred applications across all consumer segments in the United States. Sixty percent of respondents in Europe found the service appealing. Across both geographies, the appeal of the LTE Connected Car was strongest among the 'Under 35' age group.
The Connected Car concept vehicle is built upon the base of a 2010 Toyota Prius. The Toyota Prius is one of the leading hybrid electric mid-size cars in the United States. According to the US EPA in 2007, the 2008 Prius was named the most fuel-efficient car sold in the US. The EPA and California Air Resources Board also rate the Prius as among the cleanest vehicles sold in the US based on non-CO2 emissions.
LTE radio and patent pending antennae technology from Alcatel-Lucent support new advances in in-vehicle connectivity. The company's multi-screen video solution provides streaming video applications to four screens simultaneously. The LTE Connected Car system architecture puts the intelligence and computing capability in the network. Alcatel-Lucent’s historic Bell Labs invented key standards for MiMo and OFDM which support today’s smart antennae and emerging LTE networks.
QNX Software Systems provided the software foundation for the LTE Connected Car including the operating system, touchscreen user interfaces, media players for YouTube and Pandora, navigation system, Bluetooth connectivity, multimedia playback, handsfree integration, games, app store, and virtual mechanic. All components are based on the QNX CAR application platform.
Fanbase from Atlantic Records allows music fans to directly connect to their favorite artists, streamed into the LTE Connected Car. Users can chat and download the latest music, news, photos and videos from the comfort of the backseat.
chumby offers more than 1,500 applications, ranging from news and entertainment to social networks, videos, music, sports and more from high profile media partners. chumby also offers user generated content, thousands of Internet radio stations, and the ability to share photos, e-cards and more with family and friends.
The Kids VoD Service (on-demand kids’ content) from Kabillion provides high quality entertainment for young passengers in the LTE Connected Car. Kabillion’s online entertainment portal also allows kids to play games and create their own personal avatars.
It all started with a simple question. What happens if you connect a car to an ultra high-speed mobile network? Several innovative companies in very different industries were asking this same question. And when the ng Connect Program brought them together, the LTE Connected Car Service Concept was born.
And consumers are very interested! A recent Market Advantage study* of American and European consumers indicated that they are willing to pay for these innovative social, entertainment and business applications - if they are easy to use and offer a high quality of service. Navigation reigns as most the desired feature overall with Enhanced GPS and Maintenance Tracking consistently preferred applications across all consumer segments in the United States. Sixty percent of respondents in Europe found the service appealing. Across both geographies, the appeal of the LTE Connected Car was strongest among the 'Under 35' age group.
Automotive Partner
The Connected Car concept vehicle is built upon the base of a 2010 Toyota Prius. The Toyota Prius is one of the leading hybrid electric mid-size cars in the United States. According to the US EPA in 2007, the 2008 Prius was named the most fuel-efficient car sold in the US. The EPA and California Air Resources Board also rate the Prius as among the cleanest vehicles sold in the US based on non-CO2 emissions.
Technology Partners
LTE radio and patent pending antennae technology from Alcatel-Lucent support new advances in in-vehicle connectivity. The company's multi-screen video solution provides streaming video applications to four screens simultaneously. The LTE Connected Car system architecture puts the intelligence and computing capability in the network. Alcatel-Lucent’s historic Bell Labs invented key standards for MiMo and OFDM which support today’s smart antennae and emerging LTE networks.
QNX Software Systems provided the software foundation for the LTE Connected Car including the operating system, touchscreen user interfaces, media players for YouTube and Pandora, navigation system, Bluetooth connectivity, multimedia playback, handsfree integration, games, app store, and virtual mechanic. All components are based on the QNX CAR application platform.
Media and Content Partners
Fanbase from Atlantic Records allows music fans to directly connect to their favorite artists, streamed into the LTE Connected Car. Users can chat and download the latest music, news, photos and videos from the comfort of the backseat.
chumby offers more than 1,500 applications, ranging from news and entertainment to social networks, videos, music, sports and more from high profile media partners. chumby also offers user generated content, thousands of Internet radio stations, and the ability to share photos, e-cards and more with family and friends.
The Kids VoD Service (on-demand kids’ content) from Kabillion provides high quality entertainment for young passengers in the LTE Connected Car. Kabillion’s online entertainment portal also allows kids to play games and create their own personal avatars.
Thursday, February 23, 2012
Subscribe to:
Posts (Atom)