This paper presents a sample design and implementation of a CAN/WLAN/CAN interworking system using Wireless Interworking Units (WIU) that are capable of connecting remote CAN 2.0A nodes over IEEE 802.11b WLAN. This provides a straightforward solution to extend the size of distributed area of CAN networks and enables the CAN networks to communicate with other LANs utilising a low cost technology with high data rates.

Use of embedded controls units is still increasing in embedded systems like automotive, trucks... The industry trend is to develop distributed architecture, using embedded networks like CAN bus technology to link all together more and more parts as Electronic Control Units and functions. At the same time, there is the need to connect more and more extra consumer electronics products (telematics and infotainment systems, fleet management systems, Pay As You Drive equipment, black box for insurance...) to the original distributed electronic architecture of these embedded systems. By this way, electronic devices can get access to a lot of information from the car and offer more powerful added value functionality’s within always limited costs. Unfortunately, systems makers don’t allow intrusive solutions for safety, reliability reasons and for maintaining integrity of their entire systems. So, at this moment, there is no reliable and no legal way to integrate consumer electronics devices without compromising the integrity of the vehicle’s electronic system in an existing platform in aftermarket. NSI offers one way to do it thanks to it’s CAN contactless technology. Such interface acts as a 100% spy and neutral solution. It extracts data’s from the embedded networks (such CAN bus or other) without any electrical contact to networks medium. In this way, it’s compliant to system makers requirements, waranty the original integrity of their electronic architecture. There are plenty of applications for such contacless interfacing technology: fleet management system, CAN spy analyser and tools, insurance spy equipments and other after market equipments. This paper presents the main characteristics of an innovative CAN contactless solution: Technical presentation of the CAN Contactless interface, Reliability of the solution and Examples of application.

At first glance all CAN modules are very similar, the only difference being the number of message buffers which are included in the implementation. Depending on the number of buffers the module is often referred to as FullCAN or BasicCAN. A FullCAN implementation normally has an array of message buffers that can be configured as Transmit (Tx) or Receive (Rx) whereas BasicCAN has a limited amount of Tx buffers and an Rx FIFO(s). However, there are several other key requirements for a CAN module that are important in the selection of the most suitable module for an application, as they can have a big impact on the efficiency of the software. This paper discusses the main functional requirements of a CAN module for the automotive market and explores different implementations of the key requirements. Specifically, it compares implementing the requirements within a standalone module with the alternative approach of using a simpler CAN macro in conjunction with other standard MCU resources, such as system RAM, co-processor and DMA, which are not dedicated to CAN.

The paper describes the work developing a service tool to be used together with CANopen-based system. It presents the thoughts and requirements before and during the development process. The service tool has the purpose to handle design, production and service/maintenance functions in an electrical vehicle. This includes functions like diagnostics, parameter setup, reports and software download. A presentation how it has been implemented to enable all the function for both advanced users and as a user-friendly tool for non-experienced CANopen-users is also included.

The protocol stack supporting CAN (which encapsulates the overlying layers in the OSI 7 – layer abstraction model) is commonly implemented in software possibly within an OS or a task scheduler framework. Implementation of the protocol stack in software imposes memory overheads and constrains message handling when the bus is heavily loaded. Attempts to improve message handling capacity often culminate in esoteric, ROM – intensive filtering mechanisms. This paper discusses implementation of the protocol stack in an FPGA/ CPLD based platform using examples based on J1939. This results in cleaner isolation of reusable IP for the protocol stack, preserves provisions to tailor it without being limited by resources on the micro, and obviates the need of a CAN interface on the micro. Also, the paper identifies the challenges and tradeoffs involved in having this kind of a hybrid system with the user application executing off a micro, and the protocol stack realized in hardware, focusing on three key areas – time to market, rework in migrating from proven software based protocol stacks, and cost implications.

The implementation of an efficient real time networking with Controller Area Network (CAN) for distributed real time control in Hybrid Electric Vehicle (HEV) is presented. HEVs are the present potential choice for environmental friendly public transportation systems. Their safety and functionality can be improved and many value added features can be easily incorporated with CAN based distributed control. In HEV different electrical systems are functionally interconnected, requiring exchange of information accurately in real time within defined communication latency. The CAN controller reduces communications burden on the host CPU, thus allows to run its algorithms for better real time power train control. The differential physical layer improves data exchange integrity under EMI from power switching systems in this application. The implementation methodologies for TI TMS320F2406 Digital Signal Processor and PIC18F4480 Micro controller based hardware with inbuilt CAN controllers are highlighted. An efficient mailbox filter configuration and message distribution scheme in different control modules in HEV as well as state machine for minimum boot-up process for CANopen protocol in master and slave nodes are detailed.

CANopen continues to gain acceptance as a robust protocol for use in a variety of industries and applications. As this expansion occurs into new applications, the general-purpose I/O devices required by these applications are starting to push up against the limits of the CANopen Device Profile that describes them – CiA 401. In this paper, the author proposes some improvements to this venerable standard which will allow for a whole new generation of I/O devices to take full advantage of the CANopen protocol, without being unduly constrained by vestiges of the first generation which may no longer be needed. Changes to default PDO mapping, harmonizing the current behavior differences between analog and digital devices, and making sense of the Device Type object are all examined.

Communication protocols have traditionally been classified as time-triggered or event- triggered. A lot of efforts have been made to develop new protocols for control systems, e.g., LIN, TTP, TTCAN and FlexRay. The focus has rather been on the communication than on the system leading to systems designed for the communication. A system needs different types of communication in different situations. The communication has to handle time scheduled as well as sequence scheduled and event triggered messages simultaneously in an efficient controller system. CAN is the almost perfect protocol for this task. The Start of Frame ( S O F ) is well suited for synchronizing applications. Synchronized applications produce synchronized messages. By moving the timing from the communication layer to the application layer (where it belongs), CAN turns into the preferable protocol for time-triggered systems as it provides not only a robust communication during normal conditions but also during emergency situations. Unscheduable events as well as global clock failures can be handled in a predictable way.

The use of CAN with J1939 or CANopen based higher layers leads to cost efficient and flexible solutions, but together with a high increase of the electronics’ complexity. An additional complication is the typical approach of distributed development between OEMs and several suppliers. The consequence has to be a systematic improvement of the development process. Project risks are to be reduced by taking testability as a design requirement and by performing the appropriate tests in the very early project phases. This paper discusses concepts combining system prototyping with test case generation along the V-model.

Classic architectures of aircraft systems contain equipments using interfaces with digital, analogue or discrete signals. The electrical network to interface the equipments varies between the applications. Some equipment requires a dedicated power supply and provides information on an analogue current loop, while others use proprietary digital busses or discrete I/Os for information exchange. CAN initially was developed for use in the automotive industry, but is nowadays being used in an increasing number of applications. One of these areas is aviation, where CAN in the past 5 years has grown from being an exotic newcomer to an established and widely accepted solution. Within the Fire Protection System on an Airbus, smoke detectors are installed in various areas overall in the pressurized zones of the aircraft like lavatories, equipment bays and cargo compartments. As the CAN bus defines only layers 1 and 2 of the OSI communication model, additional higher layer features are necessary to achieve the level of operational assurance required for a safety critical application, namely fire protection on an aircraft. This paper is particularly focused on the development of a safety critical CAN bus network with strict configuration control of smoke detectors in the scope of an aircraft application. International airworthiness authorities in 2003 approved the application in the frame of the Airbus A318 Type certification.

Testing CAN applications requires complex test systems. Several interfaces are tested simultaneously in real-time conditions. Some components might not yet be available leertaste anzeigen and must be simulated. The simulation must be as straightforward as possible – otherwise, precious time is lost in testing the simulation rather than the real system. While specialized hardware test tools exist that cover some of these requirements, they usually do not support persistent archiving and test management. .faust is a fully configurable automatic software test system that combines aspects of quality assurance (version management, audit trails, user management,...) with requirements for real-time tests of multiple interfaces and/or components. Its kernel contains basic functions to test standard hardware protocols (CAN Bus, CANopen, LIN, Ethernet etc.), which are completed by a set of parameters describing the particularities of the component under test. A powerful scripting language offers the possibility to send, receive and process complex data or events to test diverse software interfaces and/or CAN-Bus protocols. Error situations and missing components can be simulated. Test data and results are stored in an Oracle database. In this paper we will present this tool that has been specifically designed for tests of embedded software in highly complex, safety-critical environment.

Usually gateway configurations have been based on non-standardized description formats. Unfortunately data exchange between different formats is inherently error prone and time consuming. A common description format was necessary and is found in the Field Bus Exchange Format. FIBEX is an XML-based file format, the upcoming standard for network configurations, which combines information about every aspect of a complete in-car network including controllers, channels, frames and signals. FIBEX is also the first standard to describe gateway configurations. Gateway implementations have proprietary internal formats in which they store their configuration data. Some routing information are stored as linked lists, while others are stored as executable code. An optimal gateway tool chain should be based on the FIBEX configuration data of all connected networks and translate the routing information directly into the internal format of the target implementation. The development of the tool chain at Bosch followed the development of a hardware-accelerated multi-protocol gateway. Currently the gateway connects FlexRay with CAN networks. Support for other protocols, like LIN and MOST, are planned. This paper describes the gateway hardware, gateway related enhancements to the FIBEX standard and the implementation of the tool chain to generate configuration images for the developed gateway.

AUTOSAR (AUTomotive Open System ARchitecture) aims to standardize interfaces between software application functions and further between application functions and basic software modules in ECUs (Electronic Control Unit). Independence from underlying hardware and this modular software design allows exchangeability of software functionalities amongst ECUs. The integration of functions from different suppliers is established through a virtual function bus. The mapping to a certain network topology (or to ECUs) is carried out after that step. In this paper configuration of a CAN stack and related basic software modules in system architecture development according to AUTOSAR is shown.

The paper deals with the several topics related to the development and production of the ultra low-floor tramcar, type TMK2200, for the city of Zagreb. During the development many electronic control units have been specified, designed and integrated into the vehicle. The communication between these control units is mostly based on CANopen. The reasons for selecting CANbus and CANopen application layer are discussed. Furthermore, several proprietary hardware and software solutions have been developed for this project. These solutions, among other, include redundant main vehicle control unit. The concept of this unit is presented, along with some details that increase vehicle reliability and availability. Finally, some experience facts and possible future improvements are also pointed out.

The development of simple CANopen devices up to complex systems requires exact planning and preparation. Planning and concrete realization depend each other to the extent that the selection of communication services has an effect on the performance of the assigned hardware and vice versa. The use of a prototype system enables early recognition and avoidance of bottlenecks or errors in the system. This leads to shorter development times by avoiding erroneous development and undiscovered problems in the network design. This article shows different approaches to construction, use and feasibility of prototype systems. Attention is drawn to to the scalability of the system and reuse of code from the prototypes for the target platform. In particular the codevelopment of Master/Slave applications are taken into consideration.

Time triggered network technologies are now entering into automotive electronic architecture designs. At the same time the number of ECUs integrated within a vehicle is growing, mostly integrated using CAN technology. Control applications on the next generation of vehicles will utilise LIN, CAN and FlexRay network technologies. A signal representing a real world physical quantity such as engine speed may traverse across several of these different networks. This paper investigates future requirements for the design of a vehicle’s electrical architecture. Particular attention is given to the mapping of CAN to time triggered protocols for efficient gateway design, Object Oriented Design and the XML expression of a vehicle electronic control system, and the optimisation of the electronics architecture in terms of cost and network utilisation.

A reliable communication of electrical fieldbus systems in EMI critical environments requires to precisely keep the specifications of the physical layer. Within R&D it is useful to change the topology of the connected nodes by demand and therefor fast. It is a key technology to use rapid prototyping systems to save development resources. Changes in the fieldbus topology should therefor prevent the developer of wasting time by arising communication problems. One solution for this problem could be the use of optical CAN networks. Unfortunately all components have to be prepared to be used in optical CAN networks. If only several nodes disturb the network communication by EMI problems electrical and optical mixed networks could provide a faster and cheaper solution. This paper focuses on optical and electrical mixed topologies for the CAN network. Changing the physical layer from an electrical to an optical layer means changing the topology from a bus to a star. A hub or switch becomes necessary and the support of point-2-point connections which could lead to a wire length amplification. To minimize the amount of wires a Switch, a Minibridge and a Multiplexer are proposed in this paper. The Switch supports point-2-point connections for optical nodes as well as an electrical uplink. The Minibridge connects electrical sub-segments to optical segments and supports bitwise arbitration. With the Minibridge and the Switch electrical and optical mixed bus-star-bus-topologies can be created for wire length reduction and easy connection of only electrical nodes to an optical network. The Multiplexer is necessary to merge different optical nodes to one optical network link which also leads to a wire length reduction. All proposed components support bitwise arbitration and are fully compatible to the CAN specification which is necessary for supporting electrical and optical mixed network topologies.

Research around CAN HUBs has been active, but presented solutions have not been compatible with standard high-speed physical layer. This paper introduces active HUB supporting ISO 11898-2 high-speed CAN physical layer and containing interface disable inputs for disconnection/reintegration logic introduced in recent publications. HUBs enable use of star topology, which can better fit into system’s physical structure, help avoiding uncontrolled ground currents and increase reliability. For HUB design and simulation, state-diagram based method is introduced with state- machine based behavioral CAN-bus simulation model. Timing constraints are introduced and transceiver loop-delay has found to be the most limiting parameter. Performance test computations has been verified with a prototype. The HUB supporting ISO 11898-2 physical layer can operate at any baud rate, but in real systems the HUB can operate at baud rates up to 800kbps. In addition to the interface- specific diagnostics features, HUB-based CAN-buses can ease systems designers by enabling star topology with improved tolerance against physical layer failures and without breaking the ISO 11898-2 physical layer standard.

In Automation Control Equipment, CANopen is more and more emerging because of its flexibility and openness. For larger systems one single CANopen network seems to be too restrictive. Multiple networks are the standard way of implementing such large networks, where CANopen takes the field oriented or machine oriented part. For communication over network borders, gateway functionality has already been defined in CiA309, in CiA400 and CiA446. This paper gives an overview on such functionality used in an I/O system and shows possible further evolution of gateway technology.

We present the novel concept CANopen.NET – In this concept we integrate Windows GUI-programming in .NET and control-applications based on CANopen. The integration is automated, thus no programming is needed. An increasing number of CANopen-based systems are equipped with Windows-based graphical user-interfaces (GUIs). Today, the .NET framework provides the most attractive solutions for design of GUIs both for Windows and WindowsCE based nodes. However, transferring information between the CANopen-domain (which is typically unmanaged code) and the .NET-domain (managed code) is non trivial. Traditional methods require handwritten pieces of code both in the managed and unmanaged domain for each signal (object-dictionary entry). Also, binding data values to graphical controls require hand written code. This means that adding or modifying signals to the system becomes tedious, error-prone and expensive.

The adoption of the CANOPEN fault tolerant standard by the Subsea Instrumentation Interface Standardisation (SIIS) Joint Industry Project was agreed by the SIIS panel in November 2005 . This paper presents the aims and background to the SIIS working groups decision to adopt CAN as an interface standard. For those with limited knowledge of subsea controls technology used in the offshore oil industry, the paper also provides an overview of the history and challenges of the application. The paper will then go on to discuss in more detail how CAN is being used in SIIS applications, it concludes by looking forward at planned future SIIS milestones.

The objective of this study was to develop an intelligent control system for hydraulic booms and other heavy machinery. An object oriented open source software development environment was utilized and the system was implemented using an embedded device with Linux as the operating system. The software was written in C and C++. Open standards and libraries, mainly the GNU C and C++ libraries, the POSIX standards and the CANopen communication protocol, were used. The CANopen protocol was modeled with C++ classes and presented by Unified Modeling Language (UML). A Domain-Specific Modeling language, specifically targeted at hydraulic booms, enables the initialization of the control software to different kinds of hydraulic booms and enables the modification of the control software using the concepts of the domain. By utilizing the scheduling features of the 2.6.-series Linux kernel, the control system achieved soft real-time behavior. The results were validated using both a simulated environment and a full-scale hydraulic boom.

During the last 10 years, CANopen became one of the most popular higher layer protocols for CAN-based networks. Compared with other higher layer protocols, the essential benefits of CANopen are its simplicity and flexibility which enables its use in a wide range of application areas. The versatility of CANopen is also reflected by the large number of available device, interface and application profiles. However, due to the increasing requirements of enlarging applications and systems, the maximum extension of CAN systems and the available data band width become serious limitations for the usage of CANopen in these applications. One of the most promising approaches to overcome these limitations is given by ETHERNET Powerlink, which conserves all the well appreciated CANopen mechanisms and profiles. Ethernet Powerlink is based on standard Ethernet but provides very high communication bandwith and hard real-time features. From the application point of view, there is no difference between CANopen and ETHERNET Powerlink concerning data representation, the object dictionary and the provided services. Therefore a migration becomes easy. Using gateways, CANopen and ETHERNET Powerlink systems can be interconnected smoothly.

Controller Area Network (CAN) is a popular and very well-known bus system, both in academia and in industry, initially targeted to automotive applications as a single digital bus to replace the wiring that were growing complexity, weight and cost with the advent of new automotive appliances. However, requirements have evolved and CAN’s dependability and bandwidth limitations led to the emergence of alternative networks such as FlexRay and TTP/C. Nevertheless, we believe that it is possible to improve CAN so it could fulfill contemporary requirements. This paper proposes the use of Flexible Time-Triggered CAN (FTT-CAN) to increase the available bandwidth while providing fault tolerance in CAN based systems with multiple buses. The architecture and flexibility of FTT based systems enables a tight yet flexible control of redundancy and bandwidth usage without increasing the complexity of the nodes. In this novel solution, a FTT-CAN Master controls the dispatching of messages among a set of independent buses. The Master can react online to bus failures switching the transmission of critical messages to a non-faulty bus, always keeping a pre- determined redundancy level.

TITAN©, TROJAN© & TERRIER© vehicles are the latest generation of Engineering Vehicles entering service with the British Army. TITAN© and TROJAN© are both based on the heavily armoured Challenger 2 hull having a large degree of commonality with their forebear and leant heavily on existing sub-assembly designs. CANBus was integrated into the vehicles’ electronic architecture to facilitate the trials programme. TERRIER© is an entirely new design and with it came the opportunity to integrate the latest technologies into a versatile, lightly armoured, highly manoeuvrable, tracked engineering vehicle. TERRIER© has a completely new and unique chassis and integrates COTS components over a wide range of functions. From the initial design CANBus was selected as the control bus architecture, with MilCAN as the preferred protocol. TERRIER© utilises multiple CANBus segments functionally segregated for Power Management, Command & Control, Special-to-Role and Automotive related operations. As an additional robustness measure, dual-redundant CANBus segments have been integrated in key areas.