Integration of J1939 systems in practice - CAN Newsletter Online

Standardization

Integration of J1939 systems in practice Peter Fellmeth (Vector Informatik)

C

ommercial vehicle producers are continually being confronted with problems in integrating networked systems with the J1939 protocol. Weaknesses include information exchange between OEM (original equipment manufacturer) and supplier and different variants of the J1939 standard. Initial approaches to improvement: Establish a uniform data exchange format for the CAN communication, introduce a tool for conformity testing and define mandatory device profiles. At the suggestion of key American truck manufacturers, the Vector US-subsidiary hosted a conference to discuss improvement options for J1939 networking. At this conference, a number of presenters described their concepts and experience in integrating J1939 components. In addition, weaknesses were identified, and specific optimization potentials were discussed.

J1939 is not always the same The presentation by Vector showed how the J1939 protocol takes on a different meaning in the USA, than it does in Europe [1]. The market structures that have evolved and the different technical requirements both play a role here. For example, the relationship between customer and OEM differs; a US customer not only selects the vehicle functions but the customer can also choose wheth-

56

Different development models and a potential merging er an installed ECU (electronic control unit) ï a brake ECU for example ï comes from supplier A or B. Therefore, the E / E (electric/electronic) design and communication protocol used must be as flexible as possible and must be based on standards. Typically, individual components are used across OEMs. This means that the OEM in the US has less influence on functionalities or the component manufacturer’s development processes. The role of the OEM is often limited to that of an integrator. In Europe, on the other hand, OEMs offer the vehicles in different variants. Therefore, European customers do not have the option of selecting components like their counterparts in the USA. European OEMs typically use their own chain of

fixed suppliers who individually develop or intensively modify ECUs for them. The OEM specifies the entire E / E design and sometimes the development process as well, and they are structured so that individual components can be used in different model series or brands/markets. Standards or open protocols are only needed where external interfaces are provided, e.g. in emissions-related diagnostics (OBD), fleet management (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, European OEMs tend to view J1939 more as a “toolbox” and they only use those properties actually needed

CAN Newsletter 1/2011

in the vehicle. A J1939 conformity test would be inadequate for these implementations – but the OEMs do not consider this as a disadvantage.

Reduction of development costs The presentation by Ford [2] indicates that the network architecture is not viewed as a crucial competitive advantage. So, in this area it makes sense to use standardized and largely generated software components. In its FNOS (Ford Network Operating System) initiative in the automotive area, for example, Ford took up the idea of making an implementation available to all of its suppliers. This reduced quality problems and their propagation to a minimum. The commonality between

Standardization

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 priorities do not match, specific ECU addresses are assumed or signals are not fully implemented. Navistar [3] noted that even the exchange of information between OEM and suppliers on which signals are available is a recurring source of errors due to outdated information and incomplete information. Instead of using an available quasi-standard ï such as the DBC data for-

Use of standard software components can reduce the share of application-specific software mat (CANdb database file) ï to describe the CAN communication, text documents are often used. Ford’s experience with FNOS demonstrates that

J1939 protocol software Ixxat has launched its J1939 protocol software in an extended and revised 2.02 version. An adaptation of the user interface allows for an easy extension of the software functionality with optional modules, e.g. for NMEA 2000 and ISO 11783 (Isobus). Furthermore, the updated version provides improved support of J1939 devices with dynamically adjustable addresses. The protocol software is written completely in ANSI-C. The company provides drivers required 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 configuration of the J1939 protocol software via the functional interface and therefore during runtime. This version supports 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 operating 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 micro-controllers with restricted RAM resources. With this version, the software is configured completely statically 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 considerably reduced for the J1939 protocol software. A CAN driver adapted to this version is included in the package. (hz) www.ixxat.com

58

de-facto compatibility increases the availability of products and significantly reduces integration effort. For OEMs, advantages are realized if they do not develop the reference implementation for different hardware 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 standard software components versus in-house solutions. In particular, the use of offthe-shelf components offers a number of advantages in areas that are not competition-relevant and are not typically core competencies. Purchased and in some cases pre-certified components, such as the J1939 CAN communication software or the operating system, lead to greater assurance in the development process and increase interoperability. Model-based development also contributes toward reducing sources of errors.

Optimizing the J1939 integration In its presentation, Navistar showed just how all US commercial vehicle OEMs might realize such savings potential [3]. In the context of its “Blue Diamond Program,”

CAN Newsletter 1/2011

Navistar acquired experience with both J1939 and FNOS. This involved marrying 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 chassis. It became evident that the advantages of FNOS could not simply be transferred one-to-one to J1939, but that the underlying principles could. Navistar has identified a number of items that could be improved for future J1939 integration: X The communication description should be made with an OEM-independent data format such as the DBC format. This enables automatic detection of incompatibilities or missing signals. X The OEM should have more influence in selecting the number of communicated parameter groups and signals. This offers a better way to avoid or entirely eliminate potentially critical latency times or excessively high bus loads. X Suppliers can continue to write their own communications software. A DBC database is used for improved knowledge transfer related to the communication behavior and monitoring of communication. X Exchange of simulation models between

THE ONLY REAL DISTRIBUTED CANOPEN I/O SYSTEM Z-PC LINE SENECA CPU 1 2 3 4 5 6

ETHERNET

Z-TWS

SENECA HMI

ETHERNET PLC CANOPEN MASTER

PC Interface

1 Mbps

Fiber Optic

1 Mbps Max 2 km ST connectors

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

1 Mbps

I/O SYSTEM Available 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 s-ULTI FUNCTIONCONTROLLER #!. %THERNET 2323 -OD"53245PORTONBOARD WEB server s#!.OPENlBEROPTICnBRIDGEANDREPEATER SETTINGS sCodesys Programming sEASY SuitePLUGPLAYCONlGURATIONSOFTWARE BY23 sDIP switchesADDRESS BAUDRATE

www.seneca.it

Standardization

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

Shifting effort to the beginning of the development process reduces risks and integration effort OEM and suppliers for all communication modules enables simulation and testing of the entire network. Vector CANtech [5] has analyzed these items from a cost-benefit perspective and with regard to a timeline for their introduction. The use of a common existing data exchange format between OEM and suppliers is highly recommended, since it requires little implementation effort, and the

S

ymtavision offers the SymTA/S modular toolsuite for scheduling analysis and optimization for ECUs, networks and complete embedded real-time systems. The CAN analysis library helps the carmaker to dimension and configure the CAN networks for reliable transport of both periodic and asynchronous frames. In such networks it must be ensured that all CAN messages meet deadlines or at least do not get lost during periods of heavy busloads.

M

icrocontrol has introduced a CANopen software supporting the CiA 437 application profile for photovoltaic (PV) systems. The modular CANopen NMT slave protocol stack supports all ba-

60

benefits are realized immediately. The use of a conformity test offers additional advantages. It supports the user at various points in the development process, e.g. in implementation, verification and system integration, and it improves both product quality and process effectiveness. Development tools such as Vector’s CA Noe.J1939 support automatic generation of conformity tests utilizing DBC databases. This addresses critical paths in devel-

opment much earlier in the process, so that they do not first appear in system integration. The conference showed that all of the USOEMs in attendance were working on the same problems, although at different levels of intensity. This fuels the hope that these issues might be addressed as a group. The most obvious and promising approach can be implemented with little effort: “Use of a uniform data exchange format for

ECU development tool Jitters must be in an acceptable range. Event-triggered frames disturb the periodic frame schedule, in particular in the body electronics domain. They induce a dynamic load that might vary over time and is inherently nondeterministic. CAN design, verification, and optimization suffers from the complexity of dynamic messages. As an effect, some CAN projects turn out to be over-

dimensioned and expensive, while others are underdimensioned and thus unreliable. The tool determines the static and dynamic CAN performance in various situations. The possibility to perform “what-if” analyses quickly, in combination with efficient and comprehensible dynamic load models, let the tool users perform thorough analysis of dynamics covering:

CiA 437 compliant PV software sic CANopen protocols as specified in CiA 301. Additionally, the software provides basic NMT master functions and CiA 305 layer

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

CAN Newsletter 1/2011

References: [1] Fellmeth, P.; Vector Informawtik 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.

[email protected] Dynamic load profiles Mutually exclusive scenarios X Environment dependent behavior The tool generates a set of dynamic profiles with detailed information on message and signal timing. This way, it not only determines the influence of dynamic frames on the overall CAN timing, it also allows comparison of different dynamic load situations. (hz) X X

www.symtavision.com trollers with on-chip CAN modules. The company offers also CANopen seminars for those engineers, who have no deep knowledge on CANopen. (hz) www.microcontrol.net