Commercial vehicle pro-ducers are continual-

ly being confronted with problems in integrating net-worked systems with the J1939 protocol. Weakness-es include information ex-change between OEM (orig-inal equipment manufactur-er) and supplier and differ-ent variants of the J1939 standard. Initial approaches to improvement: Establish a uniform data exchange for-mat for the CAN communi-cation, introduce a tool for conformity testing and de-fine mandatory device pro-files.

At the suggestion of key American truck manufactur-ers, the Vector US-subsid-iary hosted a conference to discuss improvement op-tions for J1939 networking. At this conference, a num-ber of presenters described their concepts and experi-ence in integrating J1939 components. In addition, weaknesses were identi-fied, and specific optimi-zation potentials were dis-cussed.

J1939 is not always the sameThe presentation by Vec-tor showed how the J1939 protocol takes on a differ-ent meaning in the USA, than it does in Europe [1]. The market structures that have evolved and the dif-ferent technical require-ments both play a role here. For example, the relation-ship between customer and OEM differs; a US customer not only selects the vehicle functions but the custom-er can also choose wheth-

er an installed ECU (elec-tronic control unit) a brake ECU for example comes from supplier A or B. There-fore, the E / E (electric/elec-tronic) design and commu-nication protocol used must be as flexible as possible and must be based on stan-dards. Typically, individu-al components are used across OEMs. This means that the OEM in the US has less influence on functional-ities or the component man-ufacturer’s development processes. The role of the OEM is often limited to that of an integrator.

In Europe, on the oth-er hand, OEMs offer the ve-hicles in different variants. Therefore, European cus-tomers do not have the op-tion of selecting components like their counterparts in the USA. European OEMs typi-cally use their own chain of

fixed suppliers who individ-ually develop or intensive-ly modify ECUs for them. The OEM specifies the en-tire E / E design and some-times the development pro-cess as well, and they are structured so that individu-al components can be used in different model series or brands/markets. Standards or open protocols are only needed where external in-terfaces are provided, e.g. in emissions-related diag-nostics (OBD), fleet man-agement (FMS), toll collect modules (OBU) or trailers (ISO 11992). This is also the case when components, e.g. the engine, is supplied to other industries such as agricultural or construction equipment. In practice, Eu-ropean OEMs tend to view J1939 more as a “toolbox” and they only use those properties actually needed

in the vehicle. A J1939 con-formity test would be inad-equate for these implemen-tations – but the OEMs do not consider this as a disad-vantage.

Reduction ofdevelopment costsThe presentation by Ford [2] indicates that the network architecture is not viewed as a crucial competitive ad-vantage. So, in this area it makes sense to use stan-dardized and largely gener-ated software components. In its FNOS (Ford Network Operating System) initiative in the automotive area, for example, Ford took up the idea of making an imple-mentation available to all of its suppliers. This reduced quality problems and their propagation to a minimum. The commonality between

Integration of J1939 systems in practice

Peter Fellmeth (Vector Informatik)

Different development models and a potential merging

56 CAN Newsletter 1/2011

Stan

dard

izat

ion

this approach and J1939 is that FNOS is like a standard for the suppliers. In contrast to FNOS, however, many J1939 users implement the standard quite differently. Participants report that this situation always leads to problems in integration. For example, messages might not be received, because sender and receiver prior-ities do not match, specif-ic ECU addresses are as-sumed or signals are not fully implemented. Navistar [3] noted that even the ex-change of information be-tween OEM and suppliers on which signals are avail-able is a recurring source of errors due to outdated infor-mation and incomplete in-formation. Instead of using an available quasi-standard

such as the DBC data for-

mat (CANdb database file) to describe the CAN com-

munication, text documents are often used.

Ford’s experience with FNOS demonstrates that

de-facto compatibility in-creases the availability of products and significantly reduces integration effort. For OEMs, advantages are realized if they do not de-velop the reference imple-mentation for different hard-ware platforms themselves. By outsourcing this work to a specialized company – in this case Vector – savings were attained on the order of about 800 000 US-$ at Ford.

Vector CANtech [4] discussed the use of stan-dard software components versus in-house solutions. In particular, the use of off-the-shelf components of-fers a number of advan-tages in areas that are not competition-relevant and are not typically core com-petencies. Purchased and in some cases pre-certified components, such as the J1939 CAN communication software or the operating system, lead to greater as-surance in the development process and increase in-teroperability. Model-based development also contrib-utes toward reducing sourc-es of errors.

Optimizing the J1939 integrationIn its presentation, Navistar showed just how all US com-mercial vehicle OEMs might realize such savings poten-tial [3]. In the context of its “Blue Diamond Program,”

Navistar acquired experi-ence with both J1939 and FNOS. This involved marry-ing a Ford cab to a Navistar chassis. A gateway (Blue Diamond Gateway) had to be developed that would act as a link between the FNOS cab and the J1939 chas-sis. It became evident that the advantages of FNOS could not simply be trans-ferred one-to-one to J1939, but that the underlying prin-ciples could. Navistar has identified a number of items that could be improved for future J1939 integration:

The communication de-scription should be made with an OEM-indepen-dent data format such as the DBC format. This enables automatic detec-tion of incompatibilities or missing signals.The OEM should have more influence in select-ing the number of com-municated parameter groups and signals. This offers a better way to avoid or entirely elimi-nate potentially critical latency times or exces-sively high bus loads.Suppliers can continue to write their own com-munications software. A DBC database is used for improved knowledge transfer related to the communication behavior and monitoring of com-munication.Exchange of simula-tion models between

Use of standard software components can reduce the share of application-specific software

Ixxat has launched its J1939 protocol software in an ex-tended and revised 2.02 version. An adaptation of the user interface allows for an easy extension of the software func-tionality with optional modules, e.g. for NMEA 2000 and ISO 11783 (Isobus). Furthermore, the updated version pro-vides improved support of J1939 devices with dynamical-ly adjustable addresses. The protocol software is written completely in ANSI-C. The company provides drivers re-quired for adapting the software to the CAN controller and target system as separate packages. Introducing the new software, Ixxat has also changed the licensing model and pricing of J1939 products. Now, a single-channel variant of the protocol software is available, which can be offered at attractive prices. Alternatively, the software is available as multi-channel variant.

The single-channel version allows dynamic config-uration of the J1939 protocol software via the functional interface and therefore during runtime. This version sup-ports a software instance (CAN channel) and is suitable for use with a real-time operating system. However, the software can also be used in an application without an op-erating system.

The multi-channel version supports several software instances (CAN channels) and several applications on one CAN channel. In addition, this version can be extended with optional packages for NMEA 2000 and ISO 15765-2 diagnostics. The other features are identical to those of the single channel version.

The micro version is optimized for use on 8-bit mi-cro-controllers with restricted RAM resources. With this version, the software is configured completely statical-ly via files that are generated with the configuration tool provided. As all configuration parameters can be placed in the Flash memory here, RAM requirement is consider-ably reduced for the J1939 protocol software. A CAN driver adapted to this version is included in the package.

www.ixxat.com

J1939 protocol software

(hz)

58 CAN Newsletter 1/2011

Stan

dard

izat

ion

www.seneca.it

THE ONLY REAL DISTRIBUTED CANOPEN I/O SYSTEM Z-PC LINE

PLC CANOPEN MASTER

PC Interface

SYSTEM HIGHLIGHTS Stand-alone Canopen devices (no gateways) Isolation at 1,5 kVac Frequency inputs (up to 10KHz) Easy Wiring via backplane (power & bus connection) Vac/dc power supply on the same hardware Address & Baud rate dip switches configuration Built-in power supply for transducers Fast Response Time: ~ 1 ms (Digital Channels);

~ 20 ms (4 Analog Channels) High accuracy of analog/temperature inputs (up to 0,01%)

I/O SYSTEMAvailable modules for:24 Digital Inputs, 24 Digital Outputs, 16 Digital Inputs / 8 Digital Outputs, 8 Analog Inputs, 3 Analog Outputs, 4 Thermoresistances, 8 Thermocouples, Strain Gauge etc. CPUs& INTERFACES

server

SETTINGSCodesys ProgrammingEASY SuiteDIP switches

SENECA CPU

SENECA HMI

ETHERNET

ETHERNET

Fiber Optic

1 Mbps

1 Mbps

1 MbpsMax 2 km

ST connectors

1 2 34 5 6

Z-TWS

OEM and suppliers for all communication mod-ules enables simulation and testing of the entire network.

Vector CANtech [5] has an-alyzed these items from a cost-benefit perspective and with regard to a time-line for their introduction. The use of a common ex-isting data exchange for-mat between OEM and sup-pliers is highly recommend-ed, since it requires little im-plementation effort, and the

Shifting effort to the beginning of the development process reduces risks and integra-tion effort

benefits are realized imme-diately. The use of a con-formity test offers addition-al advantages. It supports the user at various points in the development process, e.g. in implementation, veri-fication and system integra-tion, and it improves both product quality and process effectiveness. Develop-ment tools such as Vector’s CA Noe.J1939 support au-tomatic generation of con-formity tests utilizing DBC databases. This address-es critical paths in devel-

opment much earlier in the process, so that they do not first appear in system inte-gration.

The conference showed that all of the US-OEMs in attendance were working on the same prob-lems, although at different levels of intensity. This fu-els the hope that these is-sues might be addressed as a group. The most obvious and promising approach can be implemented with lit-tle effort: “Use of a uniform data exchange format for

CAN communication.” This offers direct benefits to both OEMs and the suppliers. A reference implementation or official conformity test tool could be defined and imple-mented in coordination with the SAE organization. Man-datory device profiles could also be established in this framework.

References:[1] Fellmeth, P.; Vector Informa-wtik GmbH: “E/E Development and J1939 in Europe, Overview about Current Status”. JEIM Congress 2010. [2] Paton, E.; Ford Motor Company: “Ford Network Operation System, The OEM perspective.” JEIM Congress 2010. [3] Venkateswaran, S.; Navistar, Inc: “Blending automotive and commercial vehicle network technologies.” JEIM Congress 2010.[4] Stevens, S.; Vector CANtech, Inc.: “Evolution of vehicle embedded software – COTs”. JEIM Congress 2010. [5] Craig, J.; Vector CANtech, Inc: ”In-vehicle network development, Best practices”. JEIM Congress 2010.

peter.fellmeth@vector.com

Symtavision offers the SymTA/S modular tool-

suite for scheduling analysis and optimization for ECUs, networks and complete em-bedded real-time systems. The CAN analysis library helps the carmaker to di-mension and configure the CAN networks for reliable transport of both periodic and asynchronous frames. In such networks it must be ensured that all CAN mes-sages meet deadlines or at least do not get lost during periods of heavy busloads.

Jitters must be in an accept-able range. Event-triggered frames disturb the periodic frame schedule, in particular in the body electronics do-main. They induce a dynam-ic load that might vary over time and is inherently non-deterministic. CAN design, verification, and optimiza-tion suffers from the com-plexity of dynamic messag-es. As an effect, some CAN projects turn out to be over-

dimensioned and expen-sive, while others are under-dimensioned and thus unre-liable. The tool determines the static and dynamic CAN performance in various sit-uations. The possibility to perform “what-if” analyses quickly, in combination with efficient and comprehensi-ble dynamic load models, let the tool users perform thor-ough analysis of dynamics covering:

ECU development tool Dynamic load profilesMutually exclusive sce-narios Environment dependent behavior

The tool generates a set of dynamic profiles with de-tailed information on mes-sage and signal timing. This way, it not only determines the influence of dynamic frames on the overall CAN timing, it also allows com-parison of different dynamic load situations.

www.symtavision.com

(hz)

Microcontrol has intro-duced a CANopen

software supporting the CiA 437 application pro-file for photovoltaic (PV) systems. The modular CANopen NMT slave pro-tocol stack supports all ba-

sic CANopen protocols as specified in CiA 301. Addi-tionally, the software pro-vides basic NMT master functions and CiA 305 layer

CiA 437 compliant PV software

setting services. Due to the CANpie driver program writ-ten in C, the software pack-et runs on most of the (32- , 16-, and 8-bit) micro-con-

trollers with on-chip CAN modules. The company of-fers also CANopen semi-nars for those engineers, who have no deep knowl-edge on CANopen.

www.microcontrol.net

60 CAN Newsletter 1/2011

Stan

dard

izat

ion

(hz)