Embedded Systems Academy

It is a busy start into 2016 with several new products and the Embedded World 2016 coming up next week.

New product – CANopen Logxaminer
Last year, we spent a lot of time helping clients to evaluate long CAN trace recordings and searching for misbehaviour of CANopen devices as well as manually generating statistics about such behaviour. In order to simplify such trace evaluations we wrote a dedicated utility that evaluates CANopen trace recordings. It supports common file formats used by recording tools from PEAK, Vector and ESAcademy.

For more information about the CANopen Logxaminer, follow the link.

New book about CAN security
Within Q2/2016 we will publish a new book, this time about CAN security. Recent publicized hacks show that CAN/CANopen are quite vulnerable, once an intruder/attacker has access to the network. Our new book introduces a scalable method that addresses both authentication and encryption, is independent of the protocol used and free sample code will be provided. A more detailed announcement will be published in our blog at www.esacademy.com/blog next week.

New 2016 price list
Our new 2016 price list is now valid, for current prices visit our CANopen online stores in Europe or USA. Prices have been lowered for the low-level entry version of our CANopen Magic tool as well as for the CANopen Magic high-end version including DLL access for custom test tool developments.

Next week’s Embedded World 2016
This years show in Nuremberg from February 23rd to 25th has almost 1000 exhibitors. For a complete list see
www.embedded-world.de/en/ausstellerprodukte/exhibitorlist

You can meet Chris or me (Olaf) from ESAcademy at the PEAK system booth. Hall 1, booth 620.

If you can not make it to the show and are still interested in selected news and updates, follow Olaf at twitter.com/ESA_Olaf or re-visit our blog after the show for a summary of impressions.

Looking forward to seeing some of you in Nuremberg

Olaf Pfeiffer

The 15th international CAN Conference took place in Vienna on October 27th and 28th 2015. On two days, a total of 23 papers were presented. Topics included current application examples, security and IoT (Internet of Things)  issues and “everything” CAN FD (Flexible Data Rate) related. CAN FD with its increased data rate was the major topic of this conference, many papers were directly related to it.

As CAN FD is not backward compatible to CAN, one of the session topics was migration from CAN to CAN FD. Mixing CAN and CAN FD controllers is only possible if the CAN FD messages are hidden from the CAN controllers as they would generate error frames upon reception. One approach is using partial networking transceivers where traditional CAN controllers are put to sleep during CAN FD communication. After seeing a specific sleep message, transceivers for partial networking can keep the connected CAN controller in sleep mode until a specific wake up message is received – no other message on the network causes a wake-up.

NXP presented a paper about their “FD Shield” transceiver. This transceiver is used to connect legacy CAN controllers to a CAN FD network. The CAN FD traffic is somewhat “shielded” from the CAN controller, only regular CAN traffic passes through but CAN FD messages are blocked as soon as they can be detected. However, there is a side effect: Each CAN FD frame on the network causes a local, not propagated receive error at the CAN controller side. As a result the CAN controller may go error passive. However, as transmits works fine, it will not go bus off and can still be used. Although not perfect, this is a quick and easy solution during a migration phase from CAN to CAN FD.

Another way to quickly connect to CAN FD networks is using Microchips external CAN FD controller using an SPI connection to the host controller. Here designers need to carefully choose the clock rate used on the serial interface side; depending on the CAN FD data rate used the SPI clock might need to be 10 or even 16Mhz. If a CAN FD data rate of 8Mbps is used, then a 10Mhz clock rate on the SPI side is sufficient to handle 100% bus load. However, the host controller of course needs to be able to handle the 10Mhz SPI traffic, too.

Other papers showed how CAN FD can be used in Linux systems, AUTOSAR and J1939, In general, the physical layout for CAN FD networks is not as flexible as it is with regular CAN. With faster bit rates ringing and reflections become more of a problem as they used to be. As usual, if an application tries to get close to the physical limits that a technology provides, more care must be taken when determining the physical layout and terminations.

With more and more CAN networks also getting some “remote access” option or even a gateway/firewall to the Internet, security of CAN networks suddenly becomes more important. In the past, CAN networks could be regarded as “closed” (inside a machinery, no remote access) so no precautions were taken in regards to security. Once a CAN network goes “online”, even if it is by the means of some firewall and even if it is only part-time, the entire security concept needs to be re-evaluated. Recent car hacks have shown that once hackers are past the firewall, they can do “anything” because there is no security layer in the CAN network.

Papers from Robert Bosch GmbH and the CiA showed some possible options to add encryption also to CAN communication, however, that directly has an impact on debugging and testing. If communication between two ECUs is secure, how do we monitor or debug it? So the debugger/tester/logger needs to part of this equation, too. It will be interesting to see where this goes, will at some point security be added to all CAN communication or will it be limit to “relevant” transmissions like commands that actually do something to the system?

Once the papers are added to the CiA’s server system, they will be available for download.

At today’s 15th international CAN conference Olaf Pfeiffer of Embedded Systems Academy presented a paper about testing of highly dynamic CANopen systems. Such systems support plug-and-play and node ID assignment by LSS (Layer Setting Services, node ID gets assigned through the network). As a result, devices may change their node ID, making tests more challenging.

One of the test utilities introduced in this paper is now available as free download from ESAcademy’s web pages. It supports the extended concise DCF (Device Configuration File) as introduced in the paper. It allows you to easily write down configuration or test sequences in a table (save as .csv) and execute them using the free CANopen File Player.

The file format, the concise Default Configuration File is part of the basic CANopen definitions and has been in use for quite some time. The extension to it is simply a definition of a set of commands introducing the option to control things like addressing specific devices (identify by CANopen Identity record 1018h) and time delays / timeouts or user interactions.

In addition, the utility can re-play previously made CAN trace recordings, supporting a wide variety of formats from Vector, PEAK and others.

For more information on the format of the extended CDCF see the manual or download the free utility.

Germany has filed an application for a new standardization project (​​NWIP):  “Road vehicles – Application profile for CAN-based network – Framework for special-purpose cars”.

This application profile specifies the CAN physical layer as well as application configuration and diagnostic parameters for the add-on devices used in special-purpose passenger cars such as taximeter, roof bar, etc. This document (also known as CiA447) specifies the physical layer, the data link layer and related communication services, the general system architecture and power management.

We believe that the creation of a new international standard would lead to further adoption and benefits for vehicle manufacturers and customizers. If there is sufficient interest we understand this project will be developed within the ISO working group TC22 SC31 WG3 “Road vehicles – Data communication – In-vehicle networks”.

If you would like to see this happen please contact Sarah Follert at CAN-in-Automation for details on who to contact in your country. Her email address is at the end of this article regarding the push for international standardization for car add-on devices.

With about 900 exhibitors the Embedded World reached a size where it is impossible to “see it all”. Yes, you can still walk by all booths in a day, but you might easily miss hidden highlights. It was quite obvious that IoT – the Internet of Things – is a current hype. To me this is quite astonishing as already some 10+ years ago we built an “Embedded Internet Demo” – at that time based on a Philips 8051 with a dial-up modem connected. The main difference between now and then is that now smart phones are widely spread and we are “always online” and now can access our embedded devices “at any time”. Among the visitors one could recognize a lot of skepticism for what exactly we really need the IoT, other then it being hip and cool to be able to control “everything” with our smart phone.

An unusual approach to get remote access to embedded applications was shown by Raisonance (http://www.iotize.com) – they have a miniature NFC or Bluetooth module that connect to the JTAG/SWD debug port of an application. So it can be added to any application with debug port, sometimes even without the need to re-compile the code, if you have the knowledge where in memory the variables are that you want to have remote access to. A great tool to get started with IoT without requiring a re-design of existing hardware.

At the CiA (CAN in Automation) booth a CAN FD demo integrated devices and tools from multiple vendors. CAN FD (Flexible Data) allows higher bit rates and longer contents (up to 64 bytes) of the data frame. Especially bootloader applications and other software update features benefit from the higher data throughput. For such applications it seems to be possible to increase the effective data throughout 8 fold easily, potentially even more.

We at ESAcademy further enhanced our portfolio of CANopen Diag products. There is now a second hardware, based on PEAK’s mini Display, that offers a subset of the diagnostic features provided at a price point of well below 1000 Euro. The CANopen Test Machine System part of the CANopen Diag now allows to create tests based on MS Visio graphs. The transitions in a state diagram can be used to transmit or receive a CAN/CANopen message or to influence/set/test/query variables or timers. More details and examples will be published shortly.

This year the Embedded World (www.embedded-world.de) in Nuremberg expects 30k+ vistors from 35+ countries. Show days are from 24th to 26th of February. For companies “into CAN” one of the hot topics is CAN FD – more and more products (microcontrollers as well as interfaces) are now available supporting the new standard supporting higher data rates. You can see the Bosch CAN FD demonstrator at the CiA booth (booth 608 in hall 1). This demo includes our CANopen Magic software connected to a CAN FD bus using the latest PEAK CAN interface. If you have questions and would like to meet us, come over to our partner PEAK System (booth 606, hall 1, just next to the CiA booth). Looking forward to seeing you!

It now has an additional function to simulate driving at a fixed speed for a fixed duration. The odometer, speed indicator and wheel pulse counter are updated accordingly.

This new feature especially helps with testing applications that measure distance traveled, like taximeters or board computers for telematic applications.

The main simulation DLL can be exchanged. If a car manufacturer publishes the required details about their gateways, the simulation provides exactly those data objects that the real car uses.

For more details and pricing please contact us.

Today we released a new version of our Micro CANopen source code. Updates and changes made include requirements from the latest CANopen conformance test as well as updates to the CiA 447 specific examples. Besides two bug fixes, the changes are:

Device switch themselves automatically to pre-operational when they detect a loss of a heartbeat that they are consuming. In the past this was application code specific, but as the conformance test requires it, we moved this function into the stack. In CiA 447 this is only done for the loss of the gateway’s heartbeat. Reaction to other heartbeat losses remains application code specific.

For CiA 447 devices, the shut down sequence is now also initiated if a gateway is not present. As before, devices wait for the next wake-up message before they try to communicate again.

Micro CANopen customers with a current maintenance and support contract may download this latest version from our servers as described on the delivery note for each product.

Although ESAcademy is not an active member of the CiA 443 group, we have several customers and business partners using CiA 443 and came across a potential reliability issue in regards to bit rate changes.

It is our understanding that the reliability requirements for CiA 443 sub-sea applications are very high. Bootloaders are written and tested in a way that even power failures at any time or severe communication errors can not break the system. In worst case, an application is not programmed and a device remains in bootloader mode and is simply re-programmed again.

However, allowing the CAN bit rate to change with the currently specified mechanisms bears the risk of one or multiple devices failing. If in a CAN network devices are not configured to use the same bit rate, communication fails at a very low level. Devices will recognize that there are errors on the bus and potentially take themselves offline (bus off). If the devices are configured to use these different bit rates, then this error state can not be resolved.

How could such a situation occur?

The Layer Setting Services (LSS, see CiA 305) allow the setup of a bit rate, if all devices connected to a network support these services. Although the method of when exactly to do the bit rate change is very well specified and synchronized, the actual storing of this information (nodes copying this information to their local non-volatile memory) is not. It happens “one-by-one” and as no timings specified, this could be within seconds or even minutes. If there are severe bus communication errors during this time or even a power failure, then all devices will not have the same bit rate configured.

Possible solutions:

1.) Do not use switching of CAN bit rates by LSS, only use it for node ID assignments

2.) Use a power-on default bit rate. Any change to the bit rates is not stored in non-volatile memory, it is only temporary. With each reset or power cycle all devices fall back to their initial default bit rate.

3.) Use auto detect. Note: this only works if not all nodes are doing it, there must be at least one node communicating for the others to be able to do an auto detection. This feature is not available with all CAN controllers (requires passive listen-only mode).

4.) Check with CiA 305 group what else can be done to make the bit rate switch safer, for example by not only synchronizing the time of the physical switch, but also the time when this information is stored into non-volatile memory.

Until this is solved we recommend all existing systems to not make use of the bit rate switching by LSS.

Recently we released a new version of CANopen Magic with significant improvements to the way user-defined CAN messages are handled. Here is a brief summary:

• Messages can now be grouped together allowing for more logical viewing and keeping messages with similar uses together
• Cut, copy and paste supports moving and copying messages between the groups
• The order of the messages in a group can be manipulated to allow quicker and easier identification
• All messages in a group can be transmitted at once
• Sequential message transmission

In particular the sequential message transmission is a useful new feature. Repeatedly clicking on a button causes the next message in the group to be transmitted. When the last message in the group has been reached transmission resumes with the first message in the group. This allows complex sequences of messages to be constructed and then transmitted, for example to provide input stimuli to a node under test at a specific point in it’s operation or to mimic transmissions from a node that has not yet been developed.

Available in CANopen Magic Standard, Professional and Ultimate starting with version 6.10. Download the evaluation version.