Technical Papers
on the Development of Embedded Electronics
Get More Information
www.vector.com
6th Edition | English
V 6.0 07/2016 - pressbook_en
Visit our website for: > News > Products > Demo software > Support > Training classes > Addresses
Vector – Automotive. Embedded. Engineering.
Stuttgart, October 2016
Status: October 2016 Responsible for content: Vector Informatik GmbH, Stuttgart All mentioned product names are either registered or nonregistered brand names of their respective owners. Continual global availability of all products or services is not guaranteed. Errors and omissions reserved. Reprint only permitted with written approval of Vector Informatik GmbH, Stuttgart. Please note: Some of the web links given in this article may be obsolete. They were valid at the time of first publication of the technical article. Illustration & Design: Cirek Mediendesign, Stuttgart, Germany
Dr. Thomas Beck
Messen/Testen/Tools Funktionale Sicherheit
Alle Bilder: Vector Informatik GmbH
Dear Reader, It is a matter of particular importance to us to present specific challenges and their solutions and to communicate the basic technological concepts of E/E development. Experts from Vector, often in collaboration with our customers, present the many different aspects of our work in technical articles and case studies. In this way we show you possible solutions for the everyday challenges you face in the development of electronics. Today, you hold in your hands the 6th edition of the collection of Vector technical articles. More than 30 new articles have been added since the last edition 18 months ago. The topics reflect the latest trends in our industry, including embedded software development in the AUTOSAR environment as well as functional safety, cyber security, and e-mobility. We hope you enjoy reading these articles.
Safety systematisch verankern Modellbasierte funktionale Sicherheit in der E/E-Systementwicklung
Um funktionale Sicherheit als integralen Bestandsteil der Entwicklung von E/E-Systemen zu ermöglichen, sind neue Ansätze nötig. Schließlich gilt es, alle Ebenen von Systementwürfen zu berücksichtigen und sicherzustell dass die Sicherheitsziele der Systeme nachweislich und gemäß der „Safety-Norm“ ISO 26262 umgesetzt sind Autoren: Albert Habermann und Dr. Simon Burto
D
ie Einführung der internationalen Norm ISO 26262 zur funktionalen Sicherheit von elektrisch/elektronischen Systemen im Automobil hat das Bewusstsein für dieses Thema in der Industrie deutlich verstärkt. Viele Hersteller und Lieferanten suchen daher nach Ansätzen, die Vorgaben aus der Norm pragmatisch und effizient zu erfüllen und gleichzeitig der steigenden Komplexität sicherheitsrelevanter Funktionen gerecht zu werden. Das Entwickeln sicherheitskritischer Systeme führt im Vergleich zu herkömmlichen Entwicklungen zu erhöhten Aufwänden. So sind zusätzliche Aktivitäten bei gleichbleibenden Rahmenbedingungen hinsichtlich Zeitplänen, Ressourcen und Kosten, unvermeidbar. Bestehende Entwicklungs-, Analyse- und Testmethoden sowie die dazugehörenden Werkzeuge sind oft fragmentiert und lassen sich nur mit großem Aufwand in einen durchgängigen Prozess integrieren.
Ganzheitliche Betrachtung von Systemarchitekturen Eine wesentliche Forderung aller gängigen Sicherheitsnormen im Automotive- sowie im Non-Automotive-Bereich (zum Beispiel IEC 34
34_Vector.indd 34
Automobil ElEktronik 02/2012
61511 Prozessindustrie, IEC61513 Kernkraftwerke, EN 50128 E bahn) besteht darin, das Erfüllen der Systemsicherheitsziele d das entwickelte Systemkonzept nachzuweisen. Sicherheitsziele den typischerweise durch Gefährdungs- und Risikoanalysen au funktionalen Systemebene identifiziert. Die aus den Sicherheitsz abgeleiteten funktionalen und technischen Sicherheitsanforderu sind dann Systemkomponenten zuzuordnen. Das korrekte Umse dieser Sicherheitsanforderungen ist durch eine geeignete Kom nation von Reviews, Analysen und Tests sicherzustellen. Das Erreichen der Systemsicherheitsziele hängt von einer Vie verschiedener Faktoren ab. Ein Beispiel hierfür sind fehlerhaft prog mierte Software-Funktionen oder zufällige Hardware-Fehler in k schen Komponenten. Solche isolierten Fehler lassen sich mit gäng Entwicklungsmethoden, wie in der ISO 26262 empfohlen, relativ fach vermeiden oder zumindest entdecken und damit beherrsc Problematischer wird es, wenn eine Kombination verschiedener temfaktoren aus unterschiedlichen Architekturebenen die Sicherh ziele beeinflusst. Mit herkömmlichen, dokumentenbasierten Entw
www.automobil-elektron
Contents
Tips and Tricks for the Use of CAPL Part 2: Effectively Apply CAPL
3/6
Tips and Tricks for the Use of CAPL Part 3: CAPL for Advanced Users
3/8
1/0
Quick Paths to a Comprehensive Remaining Bus Simulation Creative Virtual Networks Without Programming Expertise
3/14
Data Communication in the Automobil Part 2 – CAN
1/6
3/18
CAN Gets Even Better Ways to Transition from Classic CAN to the Improved CAN FD
1/12
Model-Based Development of ECUs Software Simulation with MATLAB/Simulink and CANoe
3/20
CAN FD: Fast Measurement and Reprogramming
1/16
Comprehensive Communication Tests for ECUs Developed at Volkswagen Group Identical Test Environment for Both OEM and Suppliers
Serial Bus Systems – LIN
Data Communication in the Automobil Part 3 – LIN
1/20
3/24
Serial Bus Systems – FlexRay
Data Communication in the Automobil Part 4 – FlexRay
1/26
Test Bench for Complex ECU Networks Individuality of Omnibus Features Requires a Flexible Test System
Wireless Analysis in a Multi-Protocol CAN Environment
Case Study: ZF TRW
3/29
1/32 1/36
Hardware Simulation for the Challenging Unimog Tire Pressure Control System Time Savings and New Options by ECU Tests on the Model
3/30
Acquiring Bus Data Wirelessly from Multiple Vehicles Top-notch Precision Despite the “Air Interface”
1/42
ECU Testing with XCP Support A Look Behind the Scenes
3/34
IP and Ethernet in Motor Vehicles Challenges for the Development Tool, Illustrated by Today’s Applications
1/48
Efficient ECU Tests with Fault Memory
3/38
Challenge of Ethernet Use in the Automobile Flexible Interfaces and Software Tools Simplify ECU Development
3/42
New Perspectives on Remaining Bus Simulation for Networks with SOME/IP Validating Automotive IP Network Elements
1/54
Flexible Test Systems for Efficient ECU Testing Functional Testing with Error Simulation at the Developer’s Bench
3/46
AUTOSAR Learns Ethernet
1/58
Porsche Validates Gateway ECUs Automatically Real-Time Analysis in Driving Trials Supplements Laboratory Tests
1/62
Easy Access to Bus Analysis
3/50
New Communication Paradigms in Automotive Networking Ethernet and CAN FD are the New Trailblazers
3/52
Full Transparency with Automotive Ethernet Finally Seeing what is Really Happening
1/68
Seamless Logging on Test Drives Acquire Vehicle Data Reliably with Data Loggers Case Study: GETRAG
3/55
Testing Car2x Applications Requirements for Test Tools Based on Example of the Road Works Warning
1/74
4/0
Car2x – From Research to Product Development How Automotive OEMs and Suppliers are Successfully Completing Production Car2x Projects
1/78
Automatic Validation of Diagnostic Services by Use of a Diagnostic Integration and Validation Assistant at Opel Automated Testing of Diagnostic Implementations Based on the Example of the Opel Insignia.
4/8
K-Line: Flexible Solutions for a Classic Protocol From Precise Monitoring to Data Manipulation for Generic Byte Protocols
1/84
The Standard Mix Does It Part 1: Diagnostics with AUTOSAR
4/12
Serial Bus Systems – MOST
Data Communication in the Automobil Part 5 – MOST
1/88
The Standard Mix Does It Part 2: ODX in the AUTOSAR Development Process
Design and Analysis of Functionally Safe Hardware in an Electronic Braking System (EBS)
2/0
Diagnostic Tools for WWH-OBD Implementation of the New Requirements for OEMs and Suppliers
4/16
Development of distributed Systems
2/6
Case Study: KTM
4/19
From Feature-Definition to Service-Bay Taking Advance Engineering Design Data Beyond the ‘Systems-Vee’
From Diagnostic Requirements to Communication Standardization is the Trend in the Development of Automotive Electronics
4/20
Quickly Converting Test Benches Worldwide in Record Time Record-Breaking
3/0
Diagnostics from a Distance Interactive Diagnostics for Vehicles Worldwide
4/24
Tips and Tricks for the Use of CAPL Part 1: CAPL Basics
3/4
Automated Data-driven Validation of the Diagnostic Implementation
4/28
Company Profile
Vector – The Company
Management Interview
Trends 2016: Do We Need Autonomous Driving? Interview with Dr. Beck (Member of Vector Management Board)
Serial Bus Systems
Data Communication in the Automobil Part 1 Architecture, Tasks, and Advantages of Serial Bus Systems
Serial Bus Systems – CAN
Serial Bus Systems – Automotive Ethernet
Serial Bus Systems – ITS-G5
Serial Bus Systems – K-Line
ECU Testing
These technical articles have been added since the last Pressbook edition.
Vehicle Diagnostics
Contents
ECU Calibration
AUTOSAR
Functional Safety
Calibrating ECUs Trends and Effects on Development Methods and Tools
5/0
Secure Communication for CAN FD
8/0
Analyze Large Quantities of Measurement Data Rationally and Flexibly
5/4
Integrated Development of Safety and Security Requirements
8/4
Verification of Driver Assistance Systems in the Vehicle and in the Laboratory
5/8
Cyber Security – Challenges and Practical Guidance Success Factors for Security Engineering
8/10
Calibration Data Management: A Puzzle Game No More
5/12
Cyber Security for the Automotive Industry Practical Experiences on the Application of Cyber Security
8/18
Case Study: BMW
5/17
Riding on the Razor’s Edge Optimal Parameterization of an Engine Controller for Drag Racing
5/18
Inductive Charging Gives Trigger to Future of E-Mobility ISO/IEC-15118 Standardization of Wireless Power Transfer
9/0
Case Study: HOERBIGER
5/21
9/4
5/22
Smart Testing of Smart Charging Consistent Test Case Coverage for Electric Mobility
Efficient Analysis of Model Behavior in ECU Function Development Visualize and Parameterize Simulink Models Easily and Efficiently
9/10
High-Speed Measurements for Electric and Hybrid Vehicles New Measurement Concepts Enable High Data Rates and Frequent Sampling Times
5/26
Smart Charging A Key to Successful Electric Mobility ECU Testing for Electric and Hybrid Vehicles Intelligent Measuring the Dynamic Power Consumption
9/14
Analyzing AUTOSAR ECU Software with XCP Convenient Debugging by Extending the AUTOSAR Basic Software
6/0
New Bus Interfaces for Electric/Hybrid Vehicle Development Realtime Performance Enables Flexible Use in the EV/HEV Development Field
9/18
Plug and Play Solution for AUTOSAR Software Components
6/6
9/22
AUTOSAR ECU Development Process Using DaVinci and MICROSAR from Vector
6/12
Electric Mobility Makes Great Strides 626.6 Kilometers Under Real Conditions on One Battery Charge
Case Study: FAW
Case Study: ZSW
9/27
6/19 6/20
On-Board Diagnostics Meets AUTOSAR
6/24
Convenient Charging of Electric Vehicles Smart Charging with MICROSAR IP Enables Flexible Charging Processes and Easy Payment
9/28
AUTOSAR Methodology in Practice
Case Study: AUTOSAR
6/25
10/0
AUTOSAR in Heavy-Duty Vehicles Integration of J1939 in AUTOSAR
6/26
Networking Heavy-Duty Vehicles Based on SAE J1939 From Parameter Group to Plug-and-Play Application Quo Vadis SAE J1939 Standardization
10/6
AUTOSAR – Equipped for Everything?
6/30
Integration of J1939 Systems in Practice
10/12
User-friendly Configuration of AUTOSAR ECUs with Specialized Software Tools
6/34
10/16
AUTOSAR Goes Multi-Core – the Safe Way
6/40
CAN and J1939 Under Extreme Duty Conditions Vehicle Electronics Guarantees Functionality in Cold, Ice and Snow
AUTOSAR-Compliant Development of an In-car Radio Product Using MICROSAR for the European Market
6/44
Current Trends in Network Development for Heavy-Duty Vehicles Factors of Success in Electronic Development
10/22
High-Rate Task Scheduling within AUTOSAR
6/48
10/26
New Opportunities With AUTOSAR
6/52
Automatic Interoperability Tests for ISO11783 Systems Universal Test Solution Assures Compatibility
10/30
Model-Based Functional Safety in E/E System Development
7/0
Forging New Pathways in Testing ISOBUS Task Controllers Simulations Replace Inflexible and Time-Intensive Test Methods
SilentBSW – Silent AUTOSAR Basic Software for Safety-Related ECUs Coexistence of Safety-Related and Non-Safety-Related Software in one ECU by Protecting Memory Areas
7/4
Better Test Quality by Automation Automated HIL Test System Ensures ISOBUS Functionality of Agricultural Machines
10/36
Practical Implementation of Mixed-ASIL Systems A Certified Operating System Simplifies the Development of Safety-Related Software
7/8
Development of a Cooperative Tractor-Implement Combination
10/42
Prototyping and Testing CANopen Systems Reaching Goals Rapidly with Minimal Effort
10/48
Seamless Implementation of ECU Software Based on ISO 26262
7/12
Automatic Testing of CANopen Devices
10/52
Lean Requirements Engineering
11/0
Improving Engineering Efficiency with PLM/ALM
11/4
E-Mobility
Open Networks – SAE J1939
Open Networks – ISOBUS
Open Networks – CANopen
7/18 Is this what the Future Will Look Like? Implementing Fault Tolerant System Architectures with AUTOSAR Basic Software
These technical articles have been added since the last Pressbook edition.
Automotive Cyber Security
Consulting
Vector the Company
Vector – the Company Information at a Glance
The Vector Portfolio Vector Informatik is the leading manufacturer of software tools and embedded components for the development of electronic systems and their networking with many different systems from CAN to Automotive Ethernet. Vector has been a partner of automotive manufacturers and suppliers and related industries since 1988. Vector
Development of Distributed Systems
ECU Testing
Tools and services to support you in designing and developing
Utilize these tools and services for the implementation of
networks and networked ECUs - especially for simulation,
environments and scenarios for testing ECUs and bus
analysis and testing of network communication.
communications during the entire development cycle.
Main product: PREEvision
Main products: CANoe, CANalyzer, vTESTstudio, VT System, Data Logger
tools and services provide engineers with the decisive advantage to make a challenging and highly complex subject area as simple and manageable as possible. Vector
Employees > 1,700 worldwide
Subsidiaries 20 locations in 12 countries
Diagnostics
ECU Calibration
Tools and services to describe, implement, validate and test
Tools to access the ECU at run-time for acquisition and
the diagnostic functionalities that are required to run diag-
modification of measurement data and parameters to
control technology industries rely on the solutions and
nostic services on an ECU.
optimize ECU algorithms.
products of the independent Vector Group for the develop-
Main products: CANdelaStudio, Indigo, vFlash, DiVa
Main products: CANape, VX1000, vCDM, vSignalyzer,
employees work on electronic innovations for the automotive industry every day. Worldwide customers in the automotive, commercial
vehicles,
aerospace,
transportation,
and
vADASdeveloper
ment of technologies for future mobility. Reliable Partner with Quality Our goal is excellence in all areas! Vector processes are worldwide regularly assessed and certified, and they comply with current standards: >>Quality Management - ISO 9001 >>Automotive SPICE >>Functional Safety - ISO 26262
Customers > 6,400 companies in 60 countries
Associations participation in 15 committees
ECU Software
Consulting
Software components for the ECU communication and for
Vector offers consulting for the optimization of your tech-
re-programming (flashing) via CAN, LIN, FlexRay, MOST
nical product development, the associated business
and Ethernet, real-time operating systems, AUTOSAR
processes and tools, as well as for the successful implemen-
basic software, diagnostic software, project work and
tation of change.
services.
Our offer: Consulting Services, Engineering Services
Main products: MICROSAR, Embedded Software, VC Controller, Customer Projects
– connection of the vehicle to Internet servers – are similarly
Ethernet and CAN FD
driving the industry.
The data volumes to be moved in the vehicle are increasing.
To realize the vision of autonomous driving and to exploit
Bus systems with higher bandwidth are therefore needed.
the potential of a connection to a server backbone, we must
For this reason, CAN FD and Ethernet are continuously
all become faster and more flexible and secure. Future func-
broadening their use in vehicle networks.
tions and algorithms require more powerful processors and
More flexible communication is the second aspect. Today,
operating systems with higher functionality. > E/E systems of the future must be as easily and robustly
all communication relationships, including the data rela-
modifiable in the field as possible. > Higher data volumes and data contents that change
of the vehicle starts and cannot be changed in the field.
over the service life of the vehicle must be anticipated.
tionships, are known for an E/E network when production This approach has its limits, when individual features are changed during the service life of the vehicle in order to
> The vehicle will become part of the Internet (IoT). The
make use of new services from the Internet. The rigid com-
vehicle must be protected from attacks; data to be
munication mechanism must be replaced by a dynamic one
transferred must be protected from unauthorized access.
that is much more susceptible to change and in the case of
> New services will be continuously offered over the
changes will have only local effects, for example, only on
Internet. Through modified software, vehicles already in
the sender and receiver, and not involve a large portion of
the field must be able to use new services or offer
the communication network as is the case today. For this,
refined or more secure features.
existing broadcast and multicast communication will be supplemented with point-to-point communication.
Meeting Requirements This list of requirements can be compared with the tech-
Remote Software Update
nologies and concepts that play an important role in reali-
Today, when software and its associated data are to be
Do We Need Autonomous Driving?
zation of the requirements. A few of these to which Vector
changed in the vehicle, it is necessary to bring the vehicle to
is contributing are listed below: > AUTOSAR Adaptive Platform
the shop and connect it to a tester. The tester performs the
Whoever considers trends for the coming years cannot fail to include “autonomous driving”. This topic is omnipresent and
> Ethernet with dynamic communication concepts and
tion network of the vehicle. This procedure must be ex-
dominates all others. Aviation has already solved this problem, but in a significantly simpler environment and with man-
CAN FD
task of flashing the ECUs in the vehicle via the communicapanded to include the option of supplying new software
datory legal regulations for equipment of civil aircraft. Every aircraft must have a transponder (secondary radar)
> On-Board Flashing and Remote Software Update
and data to the vehicle from the Internet via a communica-
onboard that informs other air traffic about its altitude. Modern transponders, which will be mandatory from 2017, send
> An OEM-specific service interface in the vehicle and on
tion module (GSM, LTE, WLAN). A portion of the tester
additional data, such as speed, position, course, and rate of descent or ascent. Based on this information, other air traf-
the server backbone (to be standardized), which enables
functionality migrates to the vehicle so that the software
fic can get a complete picture of the airspace since nothing flies above 3,000 or 5,000 feet (about 915 or 1,524 meters)
use of services of the vehicle by the backbone or services
updates received over the Internet can be flashed onto the
without a transponder. The airspace in this area is additionally monitored by air traffic controllers using so-called primary radar.
of a backbone in the vehicle.
relevant ECUs “onboard”. This is essential if we are to have the needed flexibility to react promptly to innovations and
All technologies and concepts are driving us in the same
to provide offers, functions, and error fixes.
direction: they are bringing the automotive industry to-
“Development activities for autonomous driving are pro-
wards the IT sector.
ducing results that will make road traffic much safer due to
Making Road Traffic Safer
a two-year-old remains elusive.” Although it is probably not
The automotive industry has a significantly more difficult
necessary to understand the whole world in order to
problem to solve. One hundred percent coverage with
autonomously steer a vehicle through traffic. Notwith-
AUTOSAR Adaptive Platform
legally required technical equipment such as transponders
standing to what extent the technical challenges can be
The AUTOSAR Adaptive Platform with the Adaptive
Examining the Service Interface
makes no sense here, because there will still be many other
solved in their entirety and to what extent that autono-
AUTOSAR API aims to make ECUs – or computer plat-
Vehicle manufacturers are already offering Internet ser-
road users that do not have the technology. To make mat-
mous driving is desired in every situation the development
forms – in the vehicle ready for future requirements. It will
vices in vehicles. Live traffic information is one example of
ters worse, automobiles must stay on the ground on the
activities on autonomous driving are producing results that
not be used on “deeply embedded” ECUs that perform
a service with high value to drivers. The vehicle can also of-
designated traffic routes. The automobile is forced into
will make road traffic much safer due to improved assis-
closed-loop and open-loop control functions. Rather, it will
fer services “to the Internet” and signal information continu-
making a model of the environment using complex algo-
tance features. And these development activities are bring-
be used in computers in the vehicle that, for example, make
ously to a server or supply data on request, such as the
rithms and sensors, such as radar, lidar, and cameras, in
ing the automotive industry together with the equally im-
use of services from the Internet, calculate tactical algo-
refinement of map materials or real-time traffic informa-
order to find a way through traffic turmoil using similarly
portant E/E sector – a good deal closer to the IT sector,
rithms for driving maneuvers, or enable intuitive operation
tion. This service offer will be significantly expanded in the
complex strategy and planning algorithms. On the issue of
which is dominated today by companies such as Google
by the user and therefore demand more flexibility from the
coming years. One service of interest from the Vector per-
“Understanding of the World through Computers”, I would
and Apple. Against this backdrop I would like to answer the
underlying operating system. Dynamic generation of tasks
spective is the diagnostic service. It will enable a server to
like to cite Richard Szeliski, a pioneer in the area of image
question posed at the beginning with an unqualified “Yes
and temporary allocation of additional memory areas are
scan the status of a vehicle or to perform checks. Vector
processing, who wrote the following in 2011: “However
we need autonomous driving”. In developing the technology
a couple of examples. Definition of a subset of the POSIX
will offer the needed software for this on both the vehicle
despite of all the advances (he is referring to the many
needed for this, the automotive industry is being raised to
standard (IEEE 1003.13) is also planned.
and server sides.
advances in the area of image processing) the dream of
a much-needed higher level of expertise in the handling of
having a computer interpret an image at the same level as
software and IT. Developments in the area of connectivity
improved assistance features.”
The drivers of autonomous driving and Car2x are shifting the automotive industry together with E/E development towards state-of-the-art IT. Vector will support its customers with smart solutions.
Trend at a Glance Autonomous driving will make road traffic safer. Development of the technology needed for this is raising the automotive industry to a higher level of expertise in the handling of software and IT.
Translation of a German publication in Elektronik automotive, issue February 2016 Image rights: Vector Informatik GmbH
Dr. Thomas Beck Dr. Thomas Beck is member of the Executive Management Board at Vector.
large that their weight and multitude of connectors was prob-
name (identifier) of the sending supermarket or home im-
lematic, not to mention the logistic challenges that arose during
provement store chain. Each receiver decides whether or
manufacturing, maintenance, and further development.
not he uses the received information. The sender pairs information and address respectively
What is a “Bus“?
identifier thus allowing the receiver to recognize the unit. In
A pioneering solution for all of these problems was the in-
transmission technology we refer to this unit as a “frame”
troduction of the so-called bus. The word “bus” comes from
because the addresses and information are framed by a
the Latin word “omnibus”, which simply means “for all”. The
start identification and end identification, which mainly
many individual cables were thus replaced by a single cable
serve to ensure error-free transmission between the sender
that is shared by all information of all electronic control
and receiver. It’s also referred to as a message or packet.
units (ECUs) (Figure 2).
Data Communication in the Automobile – Part 1: Architecture, Tasks, and Advantages of Serial Bus Systems
However, it was then necessary to find ways to organize
The Protection of Data
the timely transmission of this multitude of information
The most important tasks of a serial bus system include
over common wires. Different technologies arose, which we
timely data transmission at fast enough rates for the par-
refer to as serial bus systems.
ticular technical application and, above all, the protection
Before we delve into the specific characteristics of the indi-
of data during transmission. The use of a serial bus system
vidual bus systems in the subsequent articles in this series,
in the automobile depends in large part on the degree of
we will start by explaining the technical fundamentals of
protection needed and the amount of data per unit of time
the serial bus systems that are used in modern motor vehi-
that must be transmitted.
cles and then compare their underlying concepts.
The protection of a serial bus system depends on how well
A common characteristic of all buses is that each connected
the system prevents errors during data transmission and
ECU shares a single input and output and, unlike in networks,
how well it detects remaining data corruption. The residual
information does not have to pass through the ECUs. Thus,
error probability is one measure for this protection. This is
when one ECU sends information on a bus, all other ECUs
the product of probability A that the data to be transmit-
receive the information at almost the same time. The con-
ted are corrupted and probability B that corrupted data
dition “almost” is necessary solely on account of the signal
remain undetected. The lower the residual error probability,
transit time on copper, which is approximately 5 ns/m.
the more the data transmission is protected. There are many different causes of data corruption. The
Addresses Just Like the Post Office
most powerful are sparks from ignition plugs and electric
For smooth information exchange, the data to be sent
motors. Other galvanic, capacitive, or inductive interactions
History
to participate safely in road traffic as in self-driving cars,
must be clearly allocated to its senders and receivers. We
and electromagnetic fields also play a role. Even reflections
The first vehicles powered by gasoline engines already
also knows as autonomous. Vehicles are also starting to be
call this addressing. A general distinction is made between
at the end of the bus cable are an internal cause of data
had electrical components, such as ignition coils, contact
connected with one another and with road infrastructure
sender-selective and receiver-selective addressing. We are
errors on a serial bus. The more effective a bus is at elimi-
breakers, and spark plugs. These were quickly followed by
devices as well as with the Internet via WLAN.
familiar with both of these types of addressing from our
nating or preventing these causes, the better the data
other electrical devices such as headlights, brake lights,
However, none of these functions would be possible in the
mailbox. With sender-selective addressing, the sender de-
transmission is protected.
direction signals, interior lights, and windshield wipers. The
automobile without data exchange between electronic com-
fines the desired receiver using a unique destination ad-
A few important data protection measures are sufficient.
introduction of components for entertainment and infor-
ponents. And it is exactly this need for data exchange that
dress. This corresponds to a standard letter with a destina-
These include shielding the transmission medium (cable or wire)
mation, such as radios and record players and more recent-
has proven to be and still remains the real challenge. Initial-
tion address and return address.
and all electrical and electronic components. Alternatively
ly cassette and CD players, meant that automobiles soon
ly, a dedicated cable was used for the transmission of each
In contrast to this, receiver-selective addressing identifies
the principle of differential signal transmission (Figure 3)
contained electronic components as well. Since the 1970s,
separate information message (Figure 1). As the amount of
the information to be sent and not the ECUs. For this
electronics came along that improved or enhanced the
information grew, however, the cable harnesses became so
reason we talk about identifiers here and not addresses. We recognize deliveries like this in our mailboxes from the
functions of the vehicle itself or made driving easier. The cluding ABS and airbags, and expansion of comfort features such as air conditioning, mirror dimming and adjusting, power windows, and cruise control.
Sample Point Voltage
next stage in the 1980s was directed at driving safety, in-
Node A
Node B
Node C
Wire 1 Wire 2
Node A
Node B
Growing competition brought about by increasing global-
ΔVimpaired
ization ensured more and more innovation. Automobile manufacturers met this multifaceted challenge with electronics. The development of electronic components grew so rapidly in the 1990s that it is beyond the scope of this article to list all of the individual stages. Nowadays, the focus is on environmental friendliness and on the ability of automobiles
1/0
ΔVnormal
Node C
Disturbance symmetrical on both wires
Node E
Figure 1: Point-to-Point-Connections
Node D
Node E
Figure 2: Bus Networking
Time
Node D
Figure 3: Differential transmission on a twisted pair
1/1
Data Communication in the Automobile – Part 1
achieves a high degree of transmission protection without
Is Information Transmitted Fast Enough?
Architecture of Serial Bus Systems
(AUTomotive Open System ARchitecture, Figure 6), which
the need for real physical shielding. Shielding would be too
A bus system is regarded as capable of transmission in
Based on the reference model for data communication
provide the necessary transparency on a system or func-
expensive and does not adequately meet the requirements
real-time [1], or real-time capable, if it can guarantee suffi-
specified by the ISO (International Standardization
tion level. Cross-vendor communication standards such as
for flexibility and heat resistance. Using differential signal
ciently fast transmission of all data that accumulates for
Organization), the serial bus interface of an ECU in the
the serial bus systems CAN [2], LIN [3], FlexRay [4],
transmission, information is serially transmitted over un-
an application. The essential factors for this are the num-
automobile is generally distributed among two (communi-
MOST [5], and Ethernet [6] ensure more transparency on
shielded twisted pair with the help of voltage levels that
ber and size of messages, the available transmission speed
cation) layers. The physical layer implements the physical
the lower communication levels.
are exactly symmetrically opposed. If the voltage on one
(also referred to as bandwidth), and the bus access method
bus connection including the physical signal transmission.
CAN (Controller Area Network) is used mainly in the drive
wire increases by X volts, the voltage on the other wire
of the ECUs. For the latter, a distinction is made between
Above that is the data link layer with its tasks including
and chassis areas and in the operation of the vehicle. LIN
decreases by X volts. As a result, the electric fields in the
controlled bus access and random bus access (Figure 4).
addressing, framing, bus access, synchronization, and error
(Local Interconnect Network) is used to control simple
cables are exactly opposed and the resulting magnetic
With controlled bus access, the bus access right of an ECU
detection and correction (Figure 5).
comfort functions, such as the air conditioning, seats,
fields around the wires cancel each other almost completely.
is already defined before its bus access. Such systems are
The physical bus connection is made with help of a trans-
mirrors, and windows. MOST (Media Oriented System
Such a system hardly emits any noise. The voltage difference
called deterministic systems because it can be exactly de-
ceiver. A communication controller takes over the tasks of
Transport) has long served the infotainment area with
between the two wires represents the signal from which
termined or calculated when a particular ECU transmits
the data link layer. If all ECUs on the bus use the same type
transmission of video and audio signals that require large
external noise is subtracted.
which data. Deterministic behavior is an important precon-
of transceivers and communication controllers, the basic
bandwidths. Also Ethernet is increasingly being used for
Sufficient clearance between the data transmission and
dition for achievement of real-time. Because the entire
preconditions exist for smooth data exchange.
this. Currently, Ethernet is mainly used for diagnostics in-
power supply cables and between electrical and electronic
communication sequence runs according to schedule and
During serial communication, the sender’s application de-
cluding flashing. In the future, however, its main use will be
components is helpful. It is also essential to limit the data
can hardly be influenced, bus systems with controlled bus
livers the data block to be sent together with addresses or
in the driver assistance area, including the park assist and
transmission speed as well as the number and steepness of
access are characterized by a poor dynamic response.
identifiers to the communication controller. Check and syn-
autonomous driving sub-areas. Finally, FlexRay should en-
the data signal edges and to terminate the two bus ends
Bus systems with uncontrolled bus access avoid this dis
chronization information as well as start and end identifi-
able the most demanding communication in safety-critical
with the characteristic impedance of the transmission
advantage. Each ECU has the right to transmit data at any
cation are added, so that a frame results. The transceiver
applications such as electronically controlled steering and
medium to prevent reflections.
time. This results in a very fast bus access but also poses
now sends the frame on the bus.
braking. However, lawmakers along with the automakers
Nevertheless, transmission errors can never be fully elimi-
the following risk: Depending on the density and length of
Most buses in automobiles are in the form of a cable to
are finding it difficult to push forward here, by trying to avoid
nated, which is why error detection measures are needed.
the messages and the available bandwidth, there is a
which the ECUs are connected via short spur lines. This is
the risks in these areas that are highly critical to safety.
The checksum calculation method is most commonly used.
greater or lesser acute risk of collision. This is not an ideal
called a line topology or bus topology. On the receiver side,
CAN was developed in the early 1980s by Robert Bosch
With this method, the sender uses a defined algorithm to
basis for real-time.
the transceiver passes the frame to the communication
GmbH and became an international standard (ISO 11898)
calculate a checksum from the data to be transmitted and
If all ECUs monitor the bus continuously and send informa-
controller, which checks the information, and if data is re-
in 1994. The founders of Vector played a central role in this
includes it at the end of the message. A receiver can com-
tion only when the bus is available, the risk of collision is
ceived correctly, forwards the data block to the application.
development. LIN (ISO 17987), FlexRay (ISO 17458), and
pare this checksum with the one that it has calculated from
significantly reduced, but not fully reduced. This risk is elimi
For some tasks such as bus management, that is, the con-
MOST came from cross-vendor organizations, namely the
the received data. If the two checksums do not match,
nated altogether by introducing priorities for information,
certed putting to sleep and waking up of all ECUs, and the
LIN Consortium, FlexRay Consortium, and MOST Cooperation.
there is an error. The more sophisticated the algorithm and
which can be recognized on the CAN bus with help of the
diagnosing and configuring of ECUs, the functions of the
Vector [7] supports automobile manufacturers and suppliers
the longer the checksum, the better the data error detec-
identifier. However, even these bus access methods cannot
physical layer and the data link layers are not sufficient.
in networking using CAN, LIN, FlexRay, MOST, and Ethernet
tion capability. A checksum must not be too long, however,
guarantee timeliness (real-time). The reason is that, as a
The higher layers of the ISO reference model for higher
with a consistent set of design and development tools as
because every message in turn becomes longer and less
result of prioritization, there is a risk that messages with
communication protocols are then used in order to achieve
well as with software components and basic software for
data can be transmitted on the bus.
lower priority will be subject to long delays and no longer be
the required communication functionality.
AUTOSAR ECUs. Advice, consulting services and tools for
If an error is detected, the question arises as to how to cor-
received in a timely manner.
rect it. Errors can be corrected based on the checksum con-
Cross-Vendor Bus Technologies
A comprehensive training program that includes basic semi-
tained in a message. However, this requires longer check-
Intensified competition is ensuring more and more safety
nars for CAN, LIN, FlexRay, and Ethernet rounds out the services.
sums and, in particular, immense computing capacity in the
and comfort functions in automobiles. As a result, there is
Parts 2 to 5 of this series cover the details of the serial bus
receiving ECUs. This correction method is not used in auto-
not only a continual increase in the number of electronic
systems CAN, LIN, FlexRay, and MOST.
mobiles. Instead, the faulty message is discarded and a
components in vehicles but also a significantly higher de-
new transmission is requested.
gree of networking and a rapid rise in data volumes since
Closing Remarks About the Term “Real-Time”
most new automobile functions rely on data exchange. The
The term “real-time” is often used loosely or imprecisely,
„Bus access rights are assigned before bus access“
Centralized – Polling – Delegated Token
Controlled Bus Access
Decentralized – Token Passing – Time Division Multiple Access (TDMA)
Random Bus Access
Not collision-free – Carrier Sense Multiple Access (CSMA)
„Bus access rights are not assigned before bus access“
Collision-free – CSMA with Collision Avoidance (CSMA/CA)
process management supplement the areas of application.
Bus Node
Bus Node
challenge arising from this is to keep the increasing com-
because it is not very easy to grasp. Because I had to use it
Application
Application
plexity under control to ensure the continued quality and
at the outset, I would like to clarify a few facts about this
reliability of functions. For this purpose, the automobile
subject. Whoever wants to know more can draw on other
industry has developed standards, such as “AUTOSAR”
sources. [1]
Communication
Communication
Communication Controller
Communication Protocol
Transceiver
Physical Layer Definition
Part 9 of DIN 44300 (Information Processing), which has
Communication Controller
been replaced by DIN ISO/IEC 2382, defines real-time as follows: ”Real-time refers to the operation of a computing
Transceiver
system on which data processing programs are always
Bus
Figure 4: Controlled and random bus access
1/2
Figure 5: Architecture of serial bus systems
operable such that processing results are available within a Figure 6: AUTomotive Open System ARchitecture
specified time span. The data may occur randomly or at predefined times, depending on the application.”
1/3
For a real-time capable system, it is thus not enough to deliver a measurement or calculation result with the correct value. Rather, this also has to occur within a specified response time. If this is not the case, the system has failed. According to the theory of real-time systems, the required response time must be calculated for an application running on the system. People often speak carelessly about “real-time” if a program runs without a noticeable delay. However this definition is not very accurate. It is wrong to use “real-time“ as a synonym for “very fast“, because real-time systems even have to schedule no-load operations in order to also meet real-time requirements under high load. A distinction is made between hard real-time and soft real- time. The distinguishing criterion is the different consequences of a violation of the real-time requirements. >>Hard real-time requirements: If the system exceeds the required response time, it has failed. Real-time systems must always supply the correct result within the required response time, and the user of a hard real-time system must be able to rely on this. (For example, engine control: if the requirements are violated, the engine sputters and even damage may occur.) >>Soft real-time requirements: Such systems typically meet the required response time but not always. Thus, for example, the required response time reaches only an average or satisfies a different statistical criterion. The time requirements are not absolutely strict, but rather are viewed as guidelines. Exceeding the required response time is not regarded as a failure. It can be exceeded frequently as long as it still falls within a tolerance range. Or, the response time can far exceed the required response time occasionally. (For example, a video conference: When response time requirements are violated, the image “jerks“ but work can continue.) Literature References: [1] de.wikipedia.org/wiki/Echtzeit [2] de.wikipedia.org/wiki/Controller_Area_Network [3] de.wikipedia.org/wiki/Local_Interconnect_Network [4] de.wikipedia.org/wiki/FlexRay [5] www.mostcooperation.com [6] de.wikipedia.org/wiki/BroadR-Reach [7] www.vector.com Ernst Christmann, Physicist, Mathematician is a Senior Technical Trainer in the area of software tools for ECU testing and development and has worked for Vector Informatik GmbH in Stuttgart since 2004.
1/4
and sunroofs where it is subject to bending that can cause
Events Trigger the Transmission of Messages
wire breaks. Here the fault-tolerant CAN low-speed trans-
If a newsworthy event happens in everyday life, it is com-
ceiver with a maximum data rate of 125 kbit/s is used. It
municated in newscasts. In the world of serial buses, the
can also be operated using a single wire. Although this type
term “event” is also used to describe an occurrence that
of CAN bus is rarely used.
requires information to be transmitted. For fast communi-
The CAN interface consists of a CAN controller and a CAN
cation of information, the ideal situation is for the underly-
transceiver (Figure 2).
ing event to directly trigger transmission of the respective
The CAN controller handles the CAN protocol. The CAN
data. This is referred to as event-driven transmission.
transceiver connects the CAN controller physically to both
The alternative would be to transmit information accord-
of the CAN wires and measures or generates the voltage
ing to a prescribed schedule or time pattern. But, if infor-
levels on these two wires.
mation is now produced that requires transmission and it’s not the ECU’s turn to send, the transmission must wait.
Data Communication in the Automobile – Part 2: Reliable Data Exchange with CAN As presented in part 1 of our article series, the increasingly
physical bus connection, data rates, and the voltage levels
complex electronic systems in automobiles are calling for a
on both CAN wires.
higher level of data exchange between the ECUs. In order
To avoid this wait, CAN was developed as an event-driven
CAN uses the receiver-selective form of addressing. The
bus system. Every CAN node is authorized to access the
identifier (ID) indicates the content of the transmitted
CAN bus immediately after occurrence of an event and to
data and not the destination. A message can thus be re-
send data that has been created. The only exception is if
ceived and evaluated by all ECUs on the bus (message
another ECU is already transmitting data. Courtesy dic-
distribution). The application of a receiving ECU decides
tates that another transmission is not to be interrupted.
whether it evaluates a message. It can even set an accep-
The important thing here is that the other transmission does
tance filter in its CAN controller when starting, which hides
not last too long. CAN limits the message length to a maxi
unneeded CAN messages in the message stream based on
mum of 130 bits (for 11 bit identifiers). With the usual data
their identifiers. CAN offers two sizes of identifiers: 11 bit
transmission rate of 500 kbit/s in passenger cars, this leads
and 29 bit. The smaller identifier (standard format) is used
to a transmission duration of approximately 0.25 milli
in passenger cars. It provides 2048 different messages,
seconds. The bus is available again after that. This is an
while the larger identifier offers 536 870 912 messages. The
important precondition for data transmission that must be
latter is mainly required in commercial vehicles for CAN-
sufficiently fast for applications like drive and chassis.
based software protocols, such as SAE J1939, but is now
However, there is still a risk of collisions, namely when mul-
found in passenger cars as well.
tiple ECUs want to start transmitting messages simulta-
Receiver-selective addressing offers the following advan-
neously after the bus becomes available again after a
tages: >>Cost savings through shared use of sensors by all ECUs
transmission. This danger rises with increasing bus load. If messages were to be destroyed as a result of a collision,
CAN uses differential signal transmission, which reduces
on the bus. >>Easy implementation of distributed functions
cious cycle that would place the availability of sufficient data
to ensure this with sufficient reliability and speed, the CAN
noise sensitivity and requires two communication wires
>>It allows different configurations without adaptation of
transmission speed in doubt. To avoid this, the CSMA/CA
bus was developed. CAN stands for Controller Area Network.
(CAN high and CAN low) that are terminated at both ends
As the name implies, the CAN bus can link a larger area and
with characteristic impedance RT of 120 Ω.
access method is used in the CAN network.
The CAN bus was developed by Bosch [1] and became a
tions. It is primarily implemented by the CAN high-speed
Priorities Instead of Collisions
standard in 1993. It is currently available as ISO 11898
transceiver, which supports a maximum data rate of
When an ECU wants to send, it must check whether the
(Figure 1). The standard is divided into multiple parts. The
1 Mbit/s. The CAN low-speed physical layer has been used
bus is free (Carrier Sense – CS). If the bus is busy, the ECU
first part specifies the CAN protocol and covers all aspects
mainly in the convenience area. It is placed in doors, seats,
must wait. When the bus becomes available again, there is
reach a length up to multiple kilometers.
CAN protocol. Parts 2 and 3 of ISO 11898 describe two versions of the physical layer, namely CAN high-speed and CAN low-speed. The latter is also often called fault-tolerant CAN because it continues functioning if one of its two wires breaks, although with diminished reliability. Parts 2 and 3 also cover the physical layer of the ISO reference model, including the
(Carrier Sense Multiple Access / Collision Avoidance) bus
a possibility that other ECUs have been waiting for it too. In this case, all ECUs start sending messages (Multiple
Application software communicating with other ECUs via messages over the bus
physical layer of the ISO 7498 reference model – the sotion). The CAN controller was developed for handling the
hardware or software
Microcontroller
data integrity) and the physical signal coding as part of the called OSI layer model (OSI: Open Systems Interconnec-
this would cause the bus load to increase and initiate a vi-
CAN high-speed is mainly used in drive and chassis applica-
of the data link layer (framing, addressing, bus access,
1/6
What Has to Go from Where to Where?
ISO 7498
CAN
CAN Standard
Implementation
2 LLC Data Link MAC Layer
CAN Protocol
ISO 11898-1
CAN Controller
1 Physical Layer LLC MAC PLS PMA MDI
PLS PMA MDI
CAN Physical Layer
Logical Link Control Medium Access Control Physical Signalling Physical Medium Attachement Medium Dependant Interface
Figure 1: CAN Standard
ISO 11898-2 ISO 11898-3
CAN Transceiver
ISO 11898-1 CAN Protocol ISO 11898-2 CAN High-Speed Physical Layer ISO 11898-3 CAN Low-Speed Physical Layer
Access – MA). To avoid the impending damage from this
CAN Controller
collision (Collision Avoidance – CA or Collision Resolution –
Message completion, Controls bus access, transmission and reception of messages, bit timing
CR), a process now occurs that is referred to as bitwise
CAN Transceiver
Transmission: Translation of bits into voltage levels Reception: Voltage levels are sampled, forwarded to Controller
RT
CAN ECU
arbitration.
CAN ECU
All ECUs with a transmission request simultaneously send the identifier of their respective CAN message to be trans-
CAN_H
CAN_L
Figure 2: Structure of a CAN ECU
mitted, bitwise from the most significant to least signifiRT
cant bit. A bit with significance 0 is dominant on the CAN bus. This means if two ECUs simultaneously transmit different bit
1/7
Data Communication in the Automobile – Part 2
the CAN controller and transceiver. A bit level must last
Each receiver ensures synchronization throughout the
For example, if statistics indicate that every thousandth
is called “Wired AND bus logic” (0 = dominant, 1 = reces-
long enough on the bus that the ECUs most distant from
transmission by evaluating each falling signal edge and
message on a CAN bus exhibits an error and the CAN bus
sive). For each ID bit that is sent, each ECU compares the
the sender can still detect and evaluate it. As a result, there
adjusting its own time pattern (Bit Timing), if necessary.
operates 1000 hours per year at a data rate of 500 kbit/s,
value on the bus with the value it sent. This is called bit
is a reciprocal relationship between the bus length and
Long series of homogeneous bits do not exhibit any signal
an average bus load of 25 % and an average message
monitoring. The rules of the arbitration logic determine
transmission rate.
edges. To break these series, CAN generates additional
length of 80 bits, statistically a CAN message with an un-
signal edges by inserting a complimentary bit after five of
detected error would only occur every 4000 years.
values, the 0 value prevails over the 1 value on the bus. This
whether an ECU may continue sending or must stop (Figure 3).
Ordering and Delivering Data
equal value. This is called bit stuffing. In this way, a falling
As soon as an ECU notices an error, it aborts the message
One bit after the transmission of the identifier the arbitra-
Road traffic includes public transit buses that run accord-
edge is forced after 10 bits at the latest. After synchroniza-
transmission by sending six dominant bits. This so-called
tion ends. All ECUs that transferred a logical 1 when send-
ing to schedule and charter buses that run only when or-
tion, the receivers discard these stuff bits.
Error Flag is the proverbial bull in the china shop of the
ing their identifier but found a 0 on the bus, had to stop
dered. We find both models in CAN, too. Messages can be
The SOF (Start of Frame) is followed by either the 11 bit ID
CAN protocol. Wherever it appears, it deliberately violates
sending. Only one ECU did not have to stop and can now
sent cyclically at regular intervals or only on request.
or 29 bit ID. Its length is determined in the IDE bit (Identifier
applicable rules, i.e. in most cases the bit stuffing rule. This
transmit its entire message uncontested.
CAN buses in vehicles mainly use cyclic transmissions. CAN
Extension). IDE = 0 means short IDs. IDE = 1 means long IDs.
impairs the affected CAN transmission to such an extent
Every loser of an arbitration changes to receive mode and
buses are shorter than 40 m in passenger cars and shorter
CAN allows a maximum of eight byte payload in the data
that all ECUs on the CAN bus can also detect only locally
waits until the winner has finished transmitting its mes-
than 200 m in commercial vehicles. As a result, high trans-
field. The exact number of payload bytes is indicated using
detectable errors. A second Error Flag follows because all
sage. As soon as the bus is free again, the ECUs access it
mission rates are possible that allow cyclic sending without
a DLC (Data Length Code). The data field is followed by
other ECUs now see the error generated by the first Error
for another send attempt. In this way, the bus logic and
the bus load becoming too high.
the 15 bit check field, also called the checksum or cyclic re-
Flag. Then eight recessive bits are awaited. This is called
arbitration logic not only prevent collisions (Collision Avoid-
On long CAN buses (over a kilometer), found in building
dundancy check – CRC.
the Error Delimiter. The two Error Flags and the Error De-
ance) but also ensure a priority-controlled bus access, since
complexes or industrial plants, only low transmission rates
The sender calculates this checksum from all bits to be
limiter together are called the Error Frame (Figure 5). It is
the smaller the numerical value of an identifier, the higher
are possible. Cyclic sending of messages makes sense only
transmitted. In mathematical terms, it divides the bit string
essential for network-wide data consistency.
the priority of the related CAN message. Assuming the bus
if the cycles are correspondingly long. However, data can be
by the 15th degree polynomial 0xC599 or 1x15 + 1x14 + 1x10 + 1x8
Errors must be corrected! The sender of the corrupted mes-
is free, the message with the smallest identifier (ID = 0) is
sent on request.
+ 1x7 + 1x4 + 1x3 + 1x0 on the binary field, thus x ∈ {0,1}.
sage does this by retrying as soon as the CAN bus is free
therefore transmitted without delay. In the case of colli-
There is the Data Frame for transmitting data (Figure 4)
Each receiver does the same thing with the arriving bits. It
again, thus, after the Error Frame and ITM. However, there
sions, messages with numerically higher ID values have a
and the Remote Frame for requesting data. Because an
then compares both sequences and rates the received
is no guarantee that the retry takes place immediately be-
risk of delay as a result of losing the arbitration.
identifier indicates the content of the data, it can be used by
message in the acknowledge slot (ACK slot) following the
cause every ECU is allowed to start sending after each ITM
With a lower bus load, the probability of collisions is low.
either, the Remote Frame and the Data Frame for transmit-
recessive CRC delimiter. 0 stands for good. 1 stands for
and which message is passed through is determined by the
This type of random, nondestructive, and priority-con-
ting the requested data. The Remote Transmission Request
error. A CAN message is concluded after the recessive ACK
arbitration process. The error recovery time thus depends
trolled bus access ensures fair and very fast bus access.
(RTR) bit, included at the end of the identifier, is also used
delimiter with the 7 bit recessive EOF (End of Frame). Be-
on the message priority and the bus load.
When the bus load increases, collisions and delays of, in
for arbitration. This prevents problems if a remote frame
cause no more stuff bits are inserted after the CRC, the
What would happen if an ECU signals an error where none
particular, low priority messages accumulate. In the worst
and the associated data frame collide during arbitration. If
EOF is a one-to-one identifier for the end of the message.
existed? Active message transmissions would be aborted
case, information arrives too late at their receivers or not
RTR = 1, a Remote Frame is present. Otherwise, a Data
The EOF is followed by three recessive bits, but these no
needlessly and the communication would be disrupted. This
at all. For this reason, it is necessary to ensure when plan-
Frame is present.
longer belong to the message. They are called an Intermis-
is prevented through self-monitoring of the CAN controller
sion (ITM) or Interframe Space (IFS). Only after this is an-
using an error counter. When an ECU detects an error first,
other message permitted to be sent.
i.e. sends the first of the two Error Flags, it must increase
ning and developing a CAN bus that the bus load will not be too high.
A Bit for the Clock Comparison
The bitwise arbitration has yet another small obvious dis-
Synchronization between sender and receivers is a basic
advantage: A bit must have a long enough duration so that
precondition for the transmission of Data Frames and
Error Detection and the Bull in the China Shop
Flag, it only has to increment its counter by 1. If a message
delays in sending do not pose problems. An electrical signal
Remote Frames. For reasons of cost and effort, CAN has
The probability that errors in CAN messages remain unde-
is received without error, the counter is reduced by 1. If the
has a propagation speed of approximately 200 000 km/s
no clock line. Synchronization is realized with signal edges
tected is very low at 4.7 * 10-11 or less [2]. The CAN protocol
ECU detects the error when sending, it increases the Trans-
or 0.2 m/ns in copper. Additionally, there are delays through
and a defined mechanism. If nothing is being sent on CAN
has defined error detection mechanisms. On the receiver
mission Error Counter (TEC). Otherwise, it increases the
(bus idle), the bus level is recessive, as would be the case if
side, these include not only the CRC but also the check of
Receive Error Counter (REC). If one of these counters ex-
only bits with value 1 were being sent. For this reason, a
the format (Form Check) and the check according to the
ceeds the value 127, the CAN controller changes over to
message begins with the transmission of a dominant syn-
bit stuffing rule (Stuff Check). The sender uses bit monitor-
Error Passive mode. Consequently it can no longer send
chronization bit (Start of Frame – SOF). All receivers ad-
ing to check whether a bit level on the bus corresponds to
Error Flags consisting of dominant bits. Generating Error
just their clocks at the falling signal edge of this bit.
the send request, and it evaluates the ACK slot.
Flags with recessive level, it no longer interrupts or disturbs
Wired-AND Bus Logic: 0 = dominant
Arbitration Logic
Sender A
Sender B
Bus Level
Sender
Bus
Interpretation
0
0
0
0
0
Next
0
1
0
0
1
Fault
other ECUs, disturbing only itself while sending. The TEC
1
0
0
1
0
Stop
continues to be incremented when errors occur until it
1
1
1
1
1
Next
ID 10 ID 9 Sender A CAN Bus Sender C
1 1 1
1 1 1
ID 10 ID 9
ID 8
ID 7
ID 6
ID 5
ID 4
ID 3
ID 2
ID 1
ID 0
0
0
1
0
0
1
1
0
0
0
0
0
1
ID 8
ID 7
1
0
0
1
1
CAN node C loses arbitration Stops sending and transitions to Rx state.
Figure 3: Dominance of Zero Bit and Arbitration
1/8
its counter by 8 points. As the sender of the second Error
0
0
forces the shutdown of the ECU when value 255 is reached (Figure 6).
Error
S R I O Identifier T D F R E
r
DLC
Data Field
Checksum
1
1
4 Bits
0-8 Byte
15 Bits
11 Bits
1
Arbitration Field
1
Control Field
Figure 4: CAN Data Frame
Data Field
Check Field
D A D E C E L K L
EOF
1
7 Bits
1
1
ACK Field
Error Frame
CAN Message
(Primary) Error Flag
Figure 5: CAN Error Frame
(Secondary) Error Flag
Error Delimiter (8 bits)
CAN Messages Are Graded Every message transmission is graded by all receivers simultaneously. They all return an evaluation exactly within the ACK bit during the transmission of the sender. This is what is called an “In Transmission Response” or an “In
1/9
Frame Acknowledgment”. A dominant level corresponds to
Reliable ECU Networking
a Good grade and a recessive level to a Poor grade. Be-
Our specialists at Vector [3] support manufacturers and
cause the sender sends the ACK slot recessively, already
suppliers in the automotive industry and other industries
one Good grade is enough to confirm the correctness of the
not only in CAN networking, but also in communication sys-
message transmission. Poor grades of other ECUs would
tems such as LIN, FlexRay, CAN FD, and Ethernet.
thus be overwritten and remain unheard initially. However,
We offer consistent tool chains for planning, design, devel-
these ECUs send an Error Flag after the ACK delimiter.
opment, and maintenance as well as software components
If there is no Good evaluation at all and the ACK slot
and basic software for AUTOSAR ECUs. For getting started
remains recessive, the sender specifies an ACK error and
with ECU networking, we offer seminars on the basics of
cancels its message transmission with an Error Flag.
CAN, LIN, FlexRay, and Ethernet. To gain the necessary skills for handling the above named tools, engineers and
The Limits of CAN
technicians attend workshops where they learn all about
CAN is still the most commonly used bus technology in
the multifaceted development tasks concerning electronics
automobiles. However, CAN has systemic limits. Due to the
in automobiles [4].
principle of arbitration, CAN itself is not deterministic even
In the first part of this series [5], we addressed serial bus
during cyclic sending of messages. Using CAN, extremely
systems in general. The serial bus systems LIN, FlexRay, and
time-critical applications do not function with sufficient
MOST will be addressed in the remaining articles in the
reliability. In addition, only a maximum of one million bits
series. Interested readers will find additional in-depth in-
per second can be transmitted with CAN. Another is the
formation on the previously published topics on the Vector
high degree of reliability of CAN that makes it too expen-
E-Learning platform [6].
sive for simple applications that can manage without it. Driver assistance or autonomous driving as well as comfort
Literature References:
applications in the audio area and especially the video area
[1] de.wikipedia.org/wiki/Controller_Area_Network
require significantly higher data transmission rates and
[2] Unruh, J.; Mathony, H. J.; Kaiser, K.H: Error Detection
place higher demands on timely availability of data. Bus
Analysis of Automotive Communication Protocols. SAE
systems such as FlexRay and networks such as MOST and
International Congress 1990.
Ethernet have been established in these areas. But CAN
[3] www.vector.com
also has been further developed, and an expansion of CAN,
[4] www.vector-academy.com
called CAN FD, is now available that enables significantly
[5] Christmann, E.: Data Communication in the Automobile
higher transmission rates. The revised CAN standard
– Part 1: Architecture, Tasks, and Advantages of Serial Bus
ISO 118981:2015 containing CAN FD has been in place since
Systems
December 2015.
[6] elearning.vector.com
On the other end, LIN (Local Interconnect Network) fills the gap when it comes to cost-effective networking of sensors and actuators in the comfort area, such as for control of power windows, seats, external mirrors, sunroofs, and the air conditioning.
Reset
Error Flag
Error Active
REC > 127 oder TEC > 127
Error Passive
REC < 128 und TEC < 128 Error Flag
TEC > 255
Error Delimiter Software Reset nach 128 x 11 rezessiven Bits Bus OFF
Figure 6: States of a CAN Controller
1/10
Error Delimiter
Ernst Christmann, Physicist, Mathematician is a Senior Technical Trainer in the area of software tools for ECU testing and development and has worked for Vector Informatik GmbH in Stuttgart since 2004.
sic CAN format: the EDL bit is recessive (High level) for
addition, DBC can already handle useful data that is
CAN FD frames and dominant (Low level) for CAN frames.
64 bytes in length for protocols such as J1939.
Similarly, a recessive BRS bit switches to the higher bit rate when sending the data field. The ESI bit is used to identify
Flexible Hardware by FPGAs and Interchangeable
an error state of a CAN FD node. In addition, another four
Transceivers
bits form the Data Length Code (DLC) that covers the ex-
The structure of the software tools – and their primary
tended useful data length; its possible values are 12, 16, 20,
uses of analysis, testing, logging and simulation – reveal
24, 32, 48 and 64 bytes (Figure 1).
that CAN FD adaptations are required on nearly all layers of the automotive protocol stack. On the physical level, the
CAN Gets Even Better Ways to Transition from Classic CAN to the Improved CAN FD Robert Bosch introduced the new CAN protocol CAN FD (CAN with Flexible Data rate) in March 2012. Key new features of this protocol are that it extends the useful data length from eight to 64 bytes and offers significantly higher data transmission rates. Based on its performance data, CAN FD is positioned between High Speed CAN (1 Mbit/s) and FlexRay (10 Mbit/s). It is ideal for filling the performance gap between these bus systems at low cost. This article explains, from the perspective of a tool supplier, what needs to be modified and the effects of such changes on CAN FD development and simulation. These modifications are made on various levels: from the hardware level to potential data formats and various communication layers.
CAN FD gives the automotive industry a new foundation
tise can still be applied to CAN FD projects, since CAN FD
for better networking solutions in areas where bottlenecks
preserves existing CAN concepts such as bus arbitration,
have been occurring for years now due to growth in data
message acknowledgment, event-driven control, etc. CAN FD
traffic in vehicle electronics. This situation has resulted in
can be used very flexibly. Applications can benefit from
compromises and makeshift approaches such as subdivid-
either the higher bit rate, longer useful data length or both.
ing a network into multiple buses, which drives costs higher.
When somewhat higher transmission rates are needed due
However, switching from CAN to the higher performance
to long bus lines, e.g. in some truck applications, the useful
FlexRay is associated with high investment costs. For the
data length of up to 64 bytes helps to achieve noticeably
majority of developers a migration from the event-driven
higher data throughput.
CAN to the time-triggered FlexRay also requires enormous
Although CAN FD shares many of the same types of func-
changes to familiar ways of working and thinking.
tionality as CAN, improved protocol extensions and adap-
Challenge for Tool Suppliers
tools almost always utilize a network interface for bus ac-
For a supplier of software development tools, the challenge
cess. Network interfaces can be implemented in various
in introducing a new system such as CAN FD is to make
ways, based on either FPGAs or standard controller chips.
suitable tools available as soon as the customer group be-
The latter represent a cost-effective solution, but they are
gins to develop its first CAN FD ECUs. Integrating CAN FD
strictly limited to a specific set of functions, and they must
in an existing test and simulation environment requires
first be made available for CAN FD. The more flexible and
making rapid modifications to the various hardware levels
quickly available alternative – at least in the initial CAN FD
up to the application level. An associated database is also
phase – is to use interfaces with FPGAs. This technology
needed to describe the communication network. In this
not only fulfils the necessary real-time requirements, it also
context, the first question that should be asked is what is
enables driver updates to provide new functions such as
the best way to model CAN FD? Is a PDU abstraction nec-
64-byte support or bug fixes. The question of whether
essary, considering the useful data length of up to 64 bytes?
CAN FD needs new transceivers depends on the specific
PDUs (Protocol Data Unit) are not only commonly used
use case. In vehicle networks, it is expected that a transmis-
with FlexRay; they are also supported by the AUTOSAR
sion rate between two and four Mbit/s will be implement-
System Description. They can be used for such purposes as
ed. For flashing ECUs, however, the rate should be as high
additional CRC checks, or they can serve as Tx triggers.
as possible; eight Mbit/s or more are conceivable here, de-
Essentially, it makes sense to preserve as many of the prac-
pending on the CAN transceiver that is used. Configurable
tice-proven aspects of the CAN world as possible in model-
hardware with piggyback transceivers, i.e. small inter-
ing CAN FD. For example, it is possible to quickly migrate
changeable plug-on boards (Figure 2), offers a flexible ap-
existing CAN test and simulation systems if CAN FD is not
proach that will support future transceivers.
treated as a new bus system, but instead as an extension
On the communications level, developers often need analy-
of CAN. Then the necessary configuration changes to tools
sis tools that depict the frames and enable access to spe-
are relatively minor. It is even possible to continue to use
cific data of the frame. Here, it is absolutely essential to
test scripts and databases. Then, OEMs and suppliers
correctly interpret the new CAN FD bits EDL, BRS and ESI;
would be able to rapidly implement initial projects if they
the same applies to the extended useful data length (Figure 3).
can initially limit CAN FD to eight data bytes. It is still pos-
It is easy to make the necessary modifications by modeling
sible to use DBC databases; they are widely used in CAN
frames as events sent out by the tool. That is, it is sufficient
applications and represent the quasi industrial standard. In
to add the the CAN FD bits to existing CAN events and
tations to hardware and software are still required. Among
1/12
Evolution Instead of Revolution
other things, CAN FD introduces three new bits to the con-
For around 20 years now, CAN has been the dominant bus
trol field: the EDL (Extended Data Length), BRS (Bit Rate
system in the automotive industry, and so a broad base of
Switch) and ESI (Error State Indicator) bits. The EDL bit
developer know-how already exists in this area. This exper-
distinguishes frames in CAN FD format from those in clas-
Figure 1: CAN FD frame
1/13
CAN Gets Even Better
possible to track multiple networks back to a single one.
Translation of a German publication in Elektronik automotive,
This saves on costs by not requiring as many gateways, and
issue 04/2013
a beneficial side effect is that it eliminates undesirable gateway latencies.
Image rights:
Currently, there is no consensus on whether there will be
Vector Informatik GmbH
mixed CAN/CAN FD networks; this depends primarily on decisions by the vehicle manufacturer. Certain actions
Literature:
would definitely need to be taken to implement mixed op-
CAN FD specification V1.0, Robert Bosch GmbH
eration of CAN and CAN FD. For example, in FD operation
Figure 2: CAN FD bus interfaces with piggyback transceivers
CAN nodes need to be passively disconnected, because
Link:
they would otherwise detect a form error due to the EDL
Vector CAN Solutions: www.vector.com/can_fd
bit and would send an Error Frame. Migration from CAN to CAN FD An advanced analysis, test and simulation tool can offer
extend the useful data length to the longer length. Only
and they are systematically based on signals. They can con-
valuable assistance in nearly all situations related to the
analysis windows that display the messages need to distin-
tinue to use their simulation models, test scripts and graphic
development of CAN FD ECUs and networks. The possibili-
guish between CAN frames and CAN FD frames.
user interfaces nearly unmodified.
ties range from analyzing an individual network node to
CAN FD on Higher Layers
The Cards Have Been Reshuffled: CAN (FD), LIN, FlexRay
velopers the ability to predict future bus loads and make
On higher layers, the focus is on diagnostics, network man-
Of course, the process of introducing a new bus system has
optimal decisions based on reliable simulation data, e.g. to
agement (NM), the transport protocol (TP), interaction
some effects on current network protocols. Hardly any
determine whether or not it is necessary to make a split
layer (IL) and Tx models. While applications on the trans-
changes are expected in the convenience area of LIN, since
into several networks. The tool is used to perform remain-
port layer interpret even more frames, the application layer
CAN FD does not offer any advantages there. It must be
ing bus simulations over the course of development, which
generally no longer works with frames, but with signals in-
realized, however, that it is impossible to implement simple
substitute for a missing subnetwork and its components.
stead. Network management, the interaction layer and Tx
TP Routing (known as raw TP) with useful data greater
Simulated nodes are then be replaced by real ECUs in a
models are all dependent on specific automotive OEM re-
than eight bytes by simply copying the data of a CAN frame
step by step manner. The simulation can also serve as a
quirements. The extended useful data length of CAN FD
to a LIN frame. The situation is different with FlexRay, since
gateway, and it can connect to a new CAN FD network
affects both the interaction layer and the transport layer,
CAN FD is a more economical alternative that is always the
with a classic CAN branch. It is not necessary to make any
and so it requires modifications. The advantage of modular
preferred solution when event-driven applications are be-
modifications to existing CAN ECUs here.
tools with suitable interfaces is that not only are the
ing used. The use of FlexRay, on the other hand, is more
OEM-specific features easy to implement or interchange,
limited to real-time critical and deterministic applications.
Conclusion
but the extensions required for CAN FD are easy to imple-
Some migrations will be made in existing CAN systems.
With flexible FPGA-based network interfaces and high-per-
ment as well. On the application level, developers are in a
Networks with high bus loads of about 50 percent are can-
formance analysis, test and simulation tools, automotive
good starting situation if they have designed their applica-
didates for CAN FD. The higher bandwidth of CAN FD
OEMs and suppliers have all of the components they need
tions so that they are independent of a specific protocol
avoids splitting networks with high bus loads, and it is then
for successful CAN FD developments. The described sys-
Peter Decker has been employed at Vector Informatik GmbH in Stuttgart since 2002 and is currently Product Manager in the area of Multi-Bus Development for CANoe/CANalyzer.
fully simulating entire networks. Such a tool would give de-
tem supports different database formats and enables a variety of abstractions on the signal and PDU level. Open interfaces make it possible to implement OEM-specific properties. Network simulations and remaining bus simulations ensure optimal test conditions in all situations that occur during the development process.
Figure 3: CAN FD simulation and test tool
1/14
1/15
Tools
CAN FD: Measuring and reprogramming The complexity of the CAN FD technology is equivalent to the regular CAN network but it offers a significantly increased bandwidth. It is therefore an alternative to Flexray or Ethernet networks. Figure 1: Measurement over XCP on CAN FD with CANape
Armin Happel
Erik Sparrer
C Peter Decker Vector Informatik GmbH Ingersheimer Str. 24 DE-70499 Stuttgart Tel.: +49-711-80670-0 Fax: +49-711-80670-111 Links www.vector.com Literature: CAN-FD specification V1.0, Robert Bosch GmbH
AN with a flexible data rate (CAN FD) is a technological evolution of the CAN network. It provides more bandwidth than CAN with less complexity than Flexray. The network specialists at Vector investigated two typical applications, measurement of ECU internal signals via XCP and ECU reprogramming, using the CAN FD system.
ECU measurement with XCP on CAN FD In ECU development, the measurement and calibration of multiple signals and parameters for open and closed loop control algorithms represents an important calibration use case. ECU developers prefer to use the XCP (Universal Measurement
and Calibration Protocol) measurement and calibration protocol that has been standardized by ASAM e.V. In the current protocol version 1.2, CAN FD is introduced as a new XCP transport layer. XCP enables the utilization of measurement and calibration tools such as Vector’s CANape (Figure 1) to modify parameters during real-time operation and measure the altered behavior of the ECU. Considering a CAN system the bandwidth of the transmission medium may quickly become exhausted, depending on the number of signals to be monitored. XCP on CAN FD significantly extends the capabilities with up to 64 bytes of payload and data rates of at least 5 Mbit/s in the data phase.
CAN Newsletter 3/2014 1/16
XCP on CAN FD data throughput To estimate the maximum available data throughput of XCP over CAN respective to CAN FD, the frame size versus the available payload within a frame has been investigated for a measurement of multiple ECU signals. The data throughput calculations are based on the assumption of 100 % bus load. The actual size of the frame fields for CAN and CAN FD are shown in Table 1 and Table 2. However, frame sizes cannot be predicted precisely for either CAN or CAN FD. To assure synchronization of bus nodes to signal edges, in dependence of its content an apriori unknown amount of additional stuff bits is in-
serted into the frame. To model the stuff bit dependent frame size variation, a best and worst case scenario has been analyzed. The results of data throughput calculations are graphically represented as a sector (Figure 2, Table 3), where a frame may reside in dependent of its actual contents. To verify the theoretical calculation, a realistic measurement reflecting a practical measurement use case was processed based on a simulation environment. At the laboratory setup – which consists of CANape measurement and calibration software, suitable interface hardware and a PC-based ECU emulation – the time of flight between the in- and output of the CAN/CAN FD driver was measured in both directions. The experimentally measured values greatly meet the mathematical prediction (Figure 2, Table 5) and hence verify the modeling of the available data throughput. Comparing the acquired measurement data needed for a transmission using CAN versus CAN FD, the data throughput of CAN FD has been found to be increased by
factor 1.3 up to 5.4 depending on the system’s configuration (Table 4). Above its already improved bandwidth, XCP over CAN FD possesses further potential for improvement. Due to the equivalent physical communication basis of CAN and CAN FD, it is likely that the communication paths of existing ECU software will still be limited to an eight-byte data transmission after migrating to CAN FD. In this case XCP can only benefit from the higher data transmission rate but cannot utilize the full 64 bytes of payload available in CAN FD frames. To optimize the data transmission rate, the payload of small XCP packets could be concatenated as a large CAN FD frame (Figure 3). Vector is currently working on a proposal that enables packet concatenation for XCP over CAN FD in a future XCP specification.
Table 1: Structure of a CAN frame
Table 2: Structure of a CAN FD frame
Flash programming (Re-) programming of flash memory is the second use case in which significant improvements are expected through the utilization of
Figure 2: Measured and calculated CAN FD data throughput in ECU measurement fast network protocols. In the three flash phases “delete”, “download/program” and “verify”, the download time is a key factor in conventional CAN systems, that can be accelerated by faster bus systems such as Flexray, Ethernet and CAN FD. Regardless of the transmission protocol, it makes sense to use additional optimization strategies for downloading, such as data compression and Table 3: Calculated data throughputs of data measurement with XCP on CAN FD (fA=500 kbit/s)
Table 4: Comparison of measured data throughputs of data measurement with XCP on CAN and CAN FD
Table 5: Measured data throughputs of a data measurement with XCP on CAN FD (fA=500 kbit/s).
pipelined programming. Although compression by an LZSS (Lempel-Ziv-StorerSzymanski) algorithm reduces the volume of data to be transmitted, its efficiency is highly dependent on the data structure, and data extraction in the ECU generates additional CPU load that need to be taken into account. Pipelined programming, on the other hand, represents a type of parallelization: while a data segment is still being written in the ECU, transmission of the next segment is already started. Therefore, the potential performance gain from this method is the greatest when programming times are shorter than data transmission times. Flexray offers a transmission rate of 10 Mbit/s, but it is not fully available for (re-) programming. In the periodic communication sequence of the timetriggered protocol, all PDUs (Protocol Data Unit) are predefined in fixed slots. If many slots are reserved for diagnostic service requests such as for download, this reduces bandwidth for the useful data. Realistic configurations provide for 4 PDUs to 8 PDUs with 42 bytes to 255 bytes each per cycle for diagnose services. Vector engineers have measured download rates of 40 to 60 kB/s when pipelined programming is used.
Tools
Author
CAN Newsletter 3/2014 1/17
Tools
Ethernet with Diagnostics over IP (DoIP) per ISO 13400-2 is also well-suited for fast reprogramming of ECUs. In testing 100 Mbit Ethernet and a typical microcontroller with a pure flash write rate of 180 kB/s, results were largely a function of the buffer size of the Transfer-Data service. A 16 KiB buffer enables throughput of around 150 kB/s, which is already near the limit of the flash memory used in the test.
Reprogramming via CAN FD Since semiconductor manufacturers do not offer any microcontrollers that provide CAN FD support yet, network specialists at Vector used a microcontroller in which the CAN FD controller was implemented in an FPGA for their CAN FD measurements. The software stack on the board consists of a standard Vector UDS bootloader. The ISO 15765-2 transport layer and CAN driver were extended for support of CAN FD. To permit a quick test setup process for download testing, the CANoe simulation and testing tool was used, because the tool already offers CAN FD support. This software uses an external DLL which provides the flash programming procedure and transport layer functions. In the future, the Vector vFlash flash tool will become available for CAN FD.
Figure 4: Comparison of download and programming times with CAN and CAN FD With the transport layer that is used, the theoretically attainable transmission rate in flashing over CAN FD is 270 kB/s to 370 kB/s at 4 Mbit/s in the CAN FD data phase. However, real measured values lie well below this (Figure 4). Surprisingly, the compression and pipelining optimization strategies were counterproductive for CAN FD in the test environment that was used. The reason is that, in the laboratory setup used, the programming time for the internal flash memory became the limiting factor in the flashing process. So this made optimizations to the download phase ineffective. However, further tests with more powerful CPUs are needed
Figure 3: Faster data transmission by multiple XCP packets combined in one CAN FD frame
to arrive at more general conclusions about data throughput and the effectiveness of optimizations. A key finding of the measurements is that CAN FD delivers a significantly higher data throughput than CAN (Figure 4), and the effort required for migration is negligible.
Summary and outlook Overall, it is still difficult to arrive at an objective comparison of the serial bus systems CAN FD, Flexray and Ethernet due to their different microcontrollers and constraints, but certain tendencies can be clearly discerned. In the case of Flexray, high download speeds and high performance for the real time data payload are not both achievable at the same time. 100 Mbit Ethernet delivers the fastest transmission rates, but it requires complex software configuration, and its hardware costs are higher than for CAN FD. CAN FD appears to be the most balanced solution, it offers high data rates and the potential for further improvement at moderate costs. In addition, it is relatively easy
CAN Newsletter 3/2014 1/18
to migrate to the improved CAN, because of the close similarities between CAN and CAN FD. Both protocols are based on the same physical layer, and this enables reuse of transceivers, wiring and bus topologies. Since the communication principle has not changed either, existing know-how can still be applied. The modifications to affected software layers in calibration and reprogramming that need to be made are relatively minor. CAN FD enables significant throughput gains in both measurement and reprogramming of ECUs. In (re-) programming, this shifts the bottleneck more to the flash memory. Further development to shorten the memory access times of the MCUs that are used promise additional performance gains. Efforts by Vector to extend the XCP specifications to include packet concatenation with CAN FD also offer the potential for increasing performance of the new protocol that is still untapped.
Two features distinguish LIN from all other bus systems.
communication controller is also not required, and there is
First, there are two types of ECUs, namely a LIN Master for
not always a need for an expensive calibrated quartz as
each LIN bus and additional LIN Slaves. Second, there is a
clock. Rather, an inexpensive on-chip resonator with a fre-
possibility to produce slave ECUs in very high quantities
quency tolerance of up to ±14% will suffice. In practice,
and to sell them to vehicle manufacturers as ready-made
there is an increasing move away from the cheap RC clocks,
mass-produced goods. These high quantities reduce the
and there are now also LIN controllers available.
price further and the market supplies manufacturers with
A LIN transceiver ensures the physical bus connection. A
ECUs on which they do not have to expend any in-house
level of less than 40 % of the supply voltage is interpreted
development effort. For example, every vehicle has many
by the receiver as logical zero. A level above 60 % of the
small electric motors in seats, mirrors, windows, and sun-
supply voltage is interpreted as logical one. This large dif-
roofs. And why should any manufacturer develop their own
ference between zero and one makes the bits very immune
ECUs to control them?
to noise, but the edges are very steep, which always causes
Large suppliers offer such slave ECUs whose capabilities
electromagnetic interference. To keep this low, the maxi-
they describe in the standardized Node Capability File
mum data rate is limited to 20 kbit/s and the maximum
(NCF) using a uniform syntax, the so-called Node Capability
total capacitance is limited to 2 µF. Due to the wire capa
Language. The NCF describes performance features of a
citances and the capacitances of the transceivers, a 40 m
LIN Slave such as the frame and signal definitions, bit
long LIN bus can connect a maximum of 16 ECUs.
rates, and diagnostic parameters and is the basis for auto-
Data Communication in the Automobile – Part 3: Cost-Effective Data Exchange with LIN
mated creation of an LDF within the framework of the sys-
Like in School
tem design.
A cluster consists of a LIN Master and at least one LIN
The detailed and clearly arranged specification for LIN also
Slave. The communication is controlled by the master.
contributed to its success. The LIN Specification 2.2A [2],
Software in the microcontrollers performs the task of the
available since early 2011, defines the physical layer, the
missing communication controller. Each LIN ECU including
communication protocol, the LIN Workflow, the LIN API,
the master has a slave task. The LIN Master additionally
and the diagnostics and configuration of LIN nodes. The
has a master task that it uses to control the communica-
ISO standard for LIN (ISO 17987) has been in place since
tion (Figure 2).
January 2016. Parts 1, 2, 3, 4, and 6 will be published in the
Like in school, there is no speaking on the LIN bus without
next two months. Part 7 will follow shortly thereafter.
being called on. Like a teacher, the master task poses questions that are to be answered by the respective responsible
1/20
Dispense with Everything That is Dispensable
slave task. Sometimes, teachers ask rhetorical questions
For a long time it was customary to connect ever increasing
Consortium Facilitates the Breakthrough of LIN
The striving for cost savings is evident, especially in the de-
that they answer themselves. Likewise, the master task
numbers of sensors, actuators, and motors directly to a
An essential reason for the fast establishment of LIN was the
sign of the physical layer. An ordinary single wire must suf-
can pose questions that are answered by the slave task of
central electronic control unit (ECU). However, this trend
founding of the LIN Consortium [1] within which well-known
fice. Voltage dividers are dispensed with, and as the volt-
the master.
quickly reached its limits. The cabling effort increased,
automobile manufacturers and suppliers as well as semicon-
age level for LIN bits, the supply voltage is used for a bit
The questions are chronologically sequenced using one or
value of 1 and the vehicle ground for the bit value of 0. A
more LIN schedules that are organized into Frame Slots. At
accompanied by larger space requirements, increasing
ductor and tool manufacturers joined forces to develop a
weight, and greater noise sensitivity. More and more differ-
global communication standard for the sensor/actuator
the start of each Frame Slot, the master task transmits a
ent cable harness and connector variants became neces-
area. With the definition of a simple, cost-effective physical
Frame Header that contains the frame ID. Because this ID
sary, which in turn made production, installation, and main-
layer oriented to the K-Line (ISO 9141) as well as a simple and
is known by each slave, one slave recognizes the header as
tenance difficult. It was soon apparent that the use of a bus
lean communication protocol, the LIN Consortium laid the
a request and answers (Figure 3).
system to link components would be ideal in this area as well.
foundation for implementing simple and cost-effective ECUs.
However, CAN provides more protection than necessary for
The LIN Consortium not only focused on the actual LIN
applications such as seat, window, mirror, and air condi-
communication but also on a uniform development method,
tioning control. The costs for using CAN are too high for
the so-called LIN Workflow. However, sometimes even the
these types of components. Manufacturers therefore looked
best intentions and plans do not translate into reality. The
for cheaper solutions. Simple buses with low transmission
LIN Workflow is an example of this.
rates were developed. However, every manufacturer devel-
A uniform syntax, the LIN Configuration Language, and the
oped its own solution until price pressure forced more unity.
LIN Description File (LDF) written in this syntax are used to
LIN (Local Interconnect Network) came into being at the
describe an entire LIN cluster. The LDF describes all proper-
end of 1999. The following article explains the triumphal
ties of a LIN cluster, especially the communication of ECUs.
progression of LIN in automobiles and explains its mode of
With the help of the LDF, generation tools create the soft-
functioning.
ware components for the LIN communication. The LDF is
This technology is now used so broadly that LIN can be
also the basis for analysis, measurement, and test tools
found in almost every vehicle.
and remaining bus emulators (Figure 1).
The slave tasks recognize their respective role from the NCF
NCF
LIN Node Capability Language Specification
LIN Slave
LIN Cluster Design Tool
LIN Slave
LIN Cluster
LIN Configuration Language Specification LIN Cluster Generator
LIN Slave
LIN Master
identifier: One slave task recognizes that it must now provide the data for the requested ID in the Frame Response. Other slave tasks see that they must evaluate the antici-
LDF
Bus Analyzer Emulator LIN Bus
LIN Master
LIN Slave 2
LIN Slave 3
Slave Task
Slave Task
Slave Task
Slave Task Master Task
Figure 1: LIN Cluster
LIN Slave 1
LIN Bus
Figure 2: LIN Master and LIN Slaves
1/21
Data Communication in the Automobile – Part 3
t0 t1 t2
LIN Schedule Frame Slot 1 Frame Slot 2 Frame Slot 3
t0 LIN Master
t1
Frame Slot 1
Header 1
LIN Slave 1
Frame Slot 2 Header 2
Receive Response Frame Header
Receive Response
IFS
Frame Response
Frame Header
LIN Frame 1
to Unconditional Frames that share a common Frame Slot.
Identifier (PID). The first 60 IDs (0 to 59) are available for
But the difference is that multiple Frame Responses of dif-
payload data communication. ID=60 and ID=61 are for
ferent LIN Slaves are assigned to a common Frame Header.
diagnostics. The last two identifiers, ID=62 and ID=63, are
Which slave answers the Event Triggered Frame Header
Receive Response
reserved.
with a response depends on the need of the corresponding
The Frame Response consists of at least one and no more
LIN Slaves. A need exists when new data are to be trans-
Receive Response
than eight data bytes, followed by an 8 bit checksum for
mitted. So that the receiver knows which data it receives,
Send Response
error detection. The classic checksum was introduced in the
the PID of the underlying Unconditional Frame is transmit-
first LIN versions. Starting in LIN Version 2.0, the extended
ted in the first byte of the Frame Response of the Event
checksum is used.
Triggered Frame.
The classic checksum corresponds to the inversion of the
If multiple slaves send, a collision follows for which the LIN
modulo 256 sum of all data bytes. A receiver also generates
Master has responsibility for resolving. It interrupts the
the modulo 256 sum of the incoming bytes and as a last
schedule after the collision and inserts another schedule
step adds the incoming checksum. If the result is not 0xFF,
containing all Event Triggered Frames that share the un-
an error is present. The extended checksum includes the
lucky frame slot.
PID in the calculation.
For diagnostics of LIN Slaves, LIN provides two reserved
Header 3
Send Response
LIN Slave 3
the ID and the two parity bits are referred to as Protected Frame Slot 3
Send Response
LIN Slave 2
LIN Bus
t2
Frame Response
LIN Frame 2
IFS (Inter Frame Space) Frame Header
Frame IFS Response
LIN Frame 3
Communication Cyce
Figure 3: LIN Communication Cycle
LIN Becomes Comprehensible Only After a Calibration
pated data. The remaining slave tasks are relieved to find
Unconditional Frames. You have ID=60 for the Diagnostic
out they do not have to do anything.
For calibration, the LIN Master first sends a Sync Break in
Ample Pauses for Slow Microcontrollers
Together, the Frame Header and Frame Response yield a
order to inform all LIN Slaves of its start. With at least 13
Low-cost microcontrollers are simple and often slow. For
the ISO-TP transport protocol [3] customary in CAN as well
LIN frame. As in CAN, the ID contains a message address-
dominant bits and 1 stop bit, the length of the Sync Break
this reason, LIN allows for a small delay before beginning
as consistent diagnostic services [4, 5].
ing and every LIN ECU may read the data (broadcast).
is deliberately overexpanded in such a way that even the
the transmission of the Frame Response (Response Space)
slowest LIN Slave must detect an SCI error. Even in the
and also for send pauses (Interbyte Spaces) between the
Status and Network Management
Data Transmission Using LIN Frames
case of 12 dominant bits plus 1 stop bit, a slower LIN Slave
individual SCI frames. In this way, the Frame Response may
The LIN specification defines a status management and a
Because there is no communication controller, data is
with the allowed tolerance deviation of 14 % would still see
be prolonged by 40 % overall. The same applies to the
network management.
transmitted in LIN via the serial interface (Serial Commu-
a completely “normal” SCI frame. However, an error will be
Frame Header. However, a LIN Master does not need any
For LIN Slaves as of LIN 2.0, the status management pre-
nication Interface – SCI) of the microcontroller. Sending
detected in the 13 dominant bit because the recessive stop
pauses, because in the vast majority of cases that ECU is
scribes that detected transmission errors such as parity
occurs bitwise in CAN and bytewise in LIN. The SCI sends
bit would normally have to follow at this time. As a result of
also connected to a CAN bus. The CAN-side requirements
and checksum errors must be indicated to the LIN Master.
every byte with the least significant bit (LSB) first and
this error, the LIN Slave switches to a mode in order to
do not allow the use of inexpensive microcontrollers. The
For this purpose, a bit is needed in an Unconditional Frame
frames it with a dominant start bit (0) and a recessive stop
measure the subsequent Sync Byte. It contains the value
master uses the 40 % more time afforded to it on a longer
that the slave sends to the master (Status Frame). Addi-
bit (1). This is called an SCI frame. A LIN frame is therefore
0x55, thus a sequence of zeros and ones whose falling
Sync Break: It cuts its clock pulse rate in half so that 18
tional information about the nature of the error is possible
composed of a number of SCI frames that, because of the
edges are measured to determine the sending speed of the
dominant bits plus two recessive bits emerge. The time re-
but not mandatory. There are also not any instructions on
start bit, begin with a falling edge for synchronization
master. At the end, all LIN Slaves are calibrated to the
serve of 40 % must be taken into account in the design of
how to handle errors. The developer is responsible for this.
(Figure 4).
master with ±1.5 % accuracy.
the LIN schedule.
The task of the LIN network management is primarily to
th
Request and ID=61 for the Diagnostic Response. LIN uses
put the slaves to sleep and wake them up or, in other words,
The header contains more than just the ID, however. Due to the inexpensive, imprecisely calibrated RC clocks, the LIN
Data is not as Protected as in CAN
Four Types of Frames
to bring about the transition from normal communication
Slaves can only comprehend an ID after they have under-
The ID that now follows consists of six bits. Two parity bits
A rigid time pattern is specified through the LIN schedule.
mode (operational mode) to sleep mode, and vice versa
gone a sufficiently precise calibration process.
are used for error detection in the transmitted ID. Together,
Each header that is sent according to the LIN schedule
(Figure 5). If the LIN Slaves do not detect any bus activity
must be answered with a LIN response without any further
for four seconds, they may switch from operational mode
condition. For this reason, these types of LIN frames are called Unconditional Frames. However, the LIN specification allows this rigidity to be LIN Frame
loosened and frames to be sent only as needed. The two
Frame Header min. 14 bit
10 bit
Sync Break Sync Byte
Frame Response 10 bit
10 bit
PID
Data 1
Sync Break min. 13 bit
Sync Break Delimiter (min. 1 bit)
…
frame types “Sporadic Frame” and “Event Triggered Frame”
10 bit
10 bit
10 bit
Data 7
Data 8
Check
A Sporadic Frame is an Unconditional Frame that shares the same Frame Slot with other Unconditional Frames and is transmitted by the LIN Master as needed (header and response). Collisions are excluded because the master, as
Response Space (optional)
Start Bit
LSB
MSB
Stop Bit
the sole ECU, is the only one that may send these types of
Interbyte Space (optional)
frames. If there is no need to send the frame on the part of the master, the corresponding Frame Slot remains empty.
Useful Bits SCI Frame
1/22
Initialization
are available starting from LIN Version 2.0.
… Interbyte Space (optional)
Power On
Figure 4: LIN Frame
Event Triggered Frames communicate sporadic changes or events on the side of the LIN Slaves. They also correspond
Reception of Wake-Up-Signal or internal reason to wake up the LIN Cluster
Sleep
Reception of Sleep Command or tBus_Idle > 4 s
At the latest after 100 ms
Operational
Figure 5: LIN Network Management
1/23
to sleep mode. In LIN 2.1 and higher, they must have done so
[9] Christmann, E.: Data Communication in the Automobile
within 10 seconds. With a sleep command, the LIN Master
– Part 2: Reliable Data Exchange with CAN
can switch its slaves to sleep mode at any time.
[10] elearning.vector.com
Conversely, a LIN Slave runs through an initialization to switch from sleep mode to operational mode when it detects a wake-up signal followed by a valid header. The wake-up signal consists of a dominant pulse of at least 250 micro-
Ernst Christmann, Physicist, Mathematician is a Senior Technical Trainer in the area of software tools for ECU testing and development and has worked for Vector Informatik GmbH in Stuttgart since 2004.
seconds and no more than 5 milliseconds duration and can be sent not only by the master but from any LIN ECU. The LIN specification limits the initialization phase to 100 milliseconds. This means that the LIN Master must begin with a header after this time span at the latest. If it remains passive, the corresponding LIN Slave sends another wake-up signal. The intervals and number of repetitions of these signals are also specified. Ask the Experts Our specialists at Vector [6] support manufacturers and suppliers in the automotive industry and other industries not only in LIN networking but also in communication systems such as CAN, FlexRay, CAN FD, and Ethernet. We offer consistent tool chains for planning, design, development, and maintenance as well as software components and basic software for AUTOSAR ECUs. For an introduction to ECU networking, we offer training seminars on the basics of CAN, LIN, FlexRay, and Ethernet. We teach the necessary skills for handling the above named tools in workshops, whose goal is to quickly familiarize engineers and technicians with all aspects of the multifaceted development tasks concerning electronics in automobiles [7]. In part 1 of this series [8], we addressed serial bus systems in general. CAN was addressed in part 2 [9]. The serial bus systems FlexRay and MOST will be addressed in the remaining articles in the series. Interested readers will find
Experience With Series Projects. Count on the Worldwide Leading Solution for LIN!
additional in-depth information on the previously published topics on the Vector E-Learning platform [10]. Literature References:
Solutions for LIN
[1] www.lin-subbus.org [2] LIN Specification Package Revision 2.2A [3] Road vehicles – Diagnostics on Controller Area Network (CAN) – Part 2: Network layer services. International Standard ISO 15765-2.4, Issue 4, 2002-06-21. [4] Road vehicles – Diagnostics on Controller Area Network (CAN) – Part 3: Implementation of diagnostic services. International Standard ISO 15765-3.5, Issue 5, 2002-12-12. [5] Road vehicles – Diagnostic systems – Part 1: Diagnostic services. International Standard ISO 14229-1.6, Issue 6, 2001-02-22. [6] www.vector.com
Vector has the most comprehensive solution for every phase of your professional LIN network development: > Design your LIN networks systematically
> Make your ECUs production-ready with calibration,
> Simulate, analyze and test ECUs and entire
stress and logging tools from Vector > Rely on our Vector service teams for development,
networks efficiently with CANoe and the LIN Interfaces > Use our reliable LIN software components
training and support Visit us at: www.lin-solutions.com
[7] www.vector-academy.com [8] Christmann, E.: Data Communication in the Automobile – Part 1: Architecture, Tasks, and Advantages
1/24
For successful projects, take advantage of proven tools, scalable modules and over 25 years of networking expertise at Vector!
Vector Informatik GmbH | Germany · Austria · Brazil · China · France · India · Italy · Japan · Korea · Sweden · UK · USA | www.vector.com
Serial Bus Systems in the Automobile
That is the reason for the growing importance of communi-
Philips joined forces in the year 2000. Based on Byteflight
cation systems that guarantee fast and deterministic data
bus technology originally developed by BMW, the FlexRay
transmission in the automobile. Potential use of by-wire
Consortium created the cross-OEM, deterministic and
systems further requires the design of fault-tolerant struc-
fault-tolerant FlexRay communication standard with a
tures and mechanisms. Although by-wire systems may of-
data rate of 10 MBit/sec for extremely safety- and time-
fer wide-ranging capabilities and the benefits of increased
critical applications in the automobile.
design freedom, simplified assembly, personalization of the
Today the FlexRay Consortium is made up of seven “core
vehicle, etc., data transmission requirements in the auto-
partners”: BMW, Bosch, DaimlerChrysler, Freescale, Gener-
mobile are elevated considerably, because these systems
al Motors, Philips and Volkswagen. Gradually, a number of
belong to the class of fail-operational systems. They must
Premium Associate Members (including Vector Informatik
continue to operate acceptably even when an error occurs.
[8]) and Associate Members joined the organization.
CAN cannot satisfy these requires due to its event-driven
Making a significant contribution to the success of FlexRay
and priority-driven bus access, its limited bandwidth of
was the detailed documentation of the FlexRay specifica-
500 KBit/sec based on physical constraints in the automo-
tion. The two most important specifications, the communi-
bile, and lack of fault-tolerant structures and mechanisms [3].
cation protocol and the physical layer, are currently in Version 2.1. These and other FlexRay bus technology specifica-
FlexRay for Data Exchange in Safety-critical Applications
FlexRay – The Answer to Heightened Data Transmission
tions can be downloaded from the homepage of the
Requirements in the Automobile
FlexRay Consortium [7].
The certainty that CAN could hardly be expected to satisfy growing data transmission requirements in the automobile
FlexRay Communication Architecture – Time-triggered,
over the mid-term, led to the development of a number of
Fault Tolerant and Flexible
deterministic and fault-tolerant serial bus systems with far
Just as in the case of data communication in a CAN cluster,
greater data rates than CAN. Examples include: TTP (Time
data communication in a FlexRay cluster is also based on a
Triggered Protocol) [4], Byteflight [5] and TTCAN (Time
multi-master communication structure. However, the
Triggered CAN) [6]. Although a development partnership
FlexRay nodes are not allowed uncontrolled bus access in
FlexRay is going into production for the first time. It will appear on the BMW X5, which was presented to the public at the
was created as early as 2001 between Audi and the TTP
response to application-related events, as is the case in
Paris Auto Salon in August 2006, and it can be purchased in Germany beginning in March of this year. Within its active chas-
promoting company TTTech, and although Byteflight was
CAN. Rather they must conform to a precisely defined
sis system, FlexRay provides for secure and reliable data transmission between the central control module and the four
successfully applied to BMW 7-series cars in 2001, it is Flex-
communication cycle that allocates a specific time slot to
satellite ECUs, one located at each shock absorber. This article traces FlexRay’s path into the automobile and explains the
Ray that has prevailed in the automotive industry.
each FlexRay message (Time Division Multiple Access –
key principles of FlexRay bus technology.
An important reason for the success of FlexRay was the
TDMA) and thereby prescribes the send times of all FlexRay
founding of the FlexRay Consortium [7], under whose aus-
messages (Figure 1).
pices the two motor vehicle manufacturers DaimlerChrys-
Time-triggered communication not only ensures determin-
ler and BMW and the two chip producers Motorola and
istic data communication; it also ensures that all nodes of
According to the German Federal Statistics Office [1] driv-
In light of the goal of halving traffic fatalities by the year
ing on Germany’s roads was never so safe as in the year
2010, the automotive industry is focusing on further devel-
2005. Although vehicle registrations grew considerably,
oping existing active safety systems and driver assistance
there was a nearly one percent reduction in accidents in-
systems and developing new innovative systems. Since
volving personal injury (336619) compared to the prior year.
these systems not only provide information and instruc-
There were also significant reductions in the number of
tions, but often also make corrective interventions and as-
traffic deaths (5361, -8.2%), serious injuries (76952, -4.6 %)
sume driving tasks, it is no longer possible to do without
and minor injuries (356491, -1%). This trend was continued
electronic interfaces to the chassis and drivetrain. The
in 2006: Between January and August, 3260 traffic partic-
combination of brake-by-wire and steer-by-wire systems is
ipants were killed, and this represents a 7.8 percent reduc-
thought to have great potential.
tion compared to the prior year. The number of injured
1/26
dropped by 5.8 percent over the same time period.
Requirements of Future Data Transmission in the
Decisive in lowering the number of accidents and reducing
Automobile
the severity of accident outcomes are active safety sys-
Implementations of ever more challenging safety and driv-
tems and assistance systems that support drivers in their
er-assistance functions go hand in hand with the increas-
task of driving the vehicle. One study by a number of well-
ingly more intensive integration of electronic ECUs in the
known automotive OEMs showed, for example, that ESP
automobile. These implementations require very high data
reduced the number of skidding accidents by up to 80 % [2].
rates to transmit the increasing number of control and sta-
Making just as important a contribution to reducing the se-
tus signals. They are signals that not only need to be trans-
verity of accident outcomes are increasingly safer passen-
mitted extremely quickly; their transmission also needs to
ger cells and optimized restraint systems.
be absolutely deterministic.
Figure 1: Principle of FlexRay communication.
1/27
Serial Bus Systems in the Automobile
a FlexRay cluster can be developed and tested independent
to increase the data rate to 20 Mbit/sec. The choice be-
The communication cycle is completed by two additional
of one another. In addition, removal or addition of FlexRay
tween fault tolerance and additional bandwidth can be
time segments (Figure 1). The “Symbol Window” segment
nodes in an existing cluster must not impact the communi-
made individually for each FlexRay message.
serves to check the functionality of the Bus Guardian, and
cation process; this is consistent with the goal of re-use
Finally, an independent control mechanism (Bus Guardian)
the “Network Idle Time – NIT” time segment closes the
that is often pursued in automotive development.
ensures that a FlexRay node only gets access to the bus
communication cycle. During the NIT the FlexRay nodes
Following the paradigms of time-triggered communication
during its turn in the communication cycle. This prevents
calculate the correction factors needed to synchronize their
architectures, the underlying logic of FlexRay communica-
bus monopolization by a defective FlexRay node (babbling
tion consists of triggering all system activities when specif-
idiot).
Figure 4: Passive bus structure with two communication channels minimizes failure risk.
ic points are reached in the time cycle. The network-wide
made if necessary (the slope correction is always distributed over the entire communication cycle). There is no data
synchronism of FlexRay nodes that is necessary here, is as-
FlexRay Communication: Deterministic and Dynamic
sured by a distributed, fault-tolerant clock synchronization
Each communication cycle is equal in length and is essen-
mechanism: All FlexRay nodes not only continuously correct
tially organized into a static time segment and a dynamic
However, it is not mandatory to transmit the FlexRay mes-
CRC-protected Data Transmission
for the beginning times (offset correction) of regularly
time segment (Figure 1). Of central importance here is the
sages associated to the minislots with each communica-
The signals in a FlexRay cluster are transmitted by the
transmitted synchronization messages; they also correct
static segment that begins each communication cycle. It is
tion cycle, rather they are only sent as needed. If messages
well-defined FlexRay message, wherein there is essentially
for the duration (slope correction) of the communication
subdivided into a user-definable number (maximum 1023)
are not needed, the slot counter of a minislot is increment-
no difference in the formats of the FlexRay messages
cycles (Figure 2). This increases both the bandwidth effi-
of equally long static slots.
ed after the defined time period. While a (dynamic) FlexRay
transmitted in the static segment and those transmitted in
ciency and robustness of the synchronization.
Each static slot is assigned to a FlexRay message to be sent
message is being transmitted, incrementing of the slot
the dynamic segment. They are each composed of a head-
FlexRay communication can be based on either an electri-
by a FlexRay node. Assignments of static slots, FlexRay
counter is delayed by the message transmission time
er, payload and trailer (Figure 6).
cal or optical physical layer. Speaking in favor of electrical
messages and FlexRay nodes are made by slot number,
(Figure 5).
The header comprises the five-bit wide status field, ID, pay-
signal transmission is its simplicity, which brings cost ad-
message identifier (ID), and the value of the slot counter
The allocation of a dynamic FlexRay message to a minislot
load length and cycle counter. The header-CRC (11 bits)
vantages. The comparatively cost-intensive optical signal
implemented on each FlexRay node. To ensure that all
implicitly defines the priority of the FlexRay message: The
protects parts of the status field, ID and payload length
transmission is characterized by substantially better elec-
FlexRay messages are transmitted at the right time and in
lower the number of the minislot, the higher the priority of
with a Hamming distance of 6. The ID identifies the FlexRay
tromagnetic compatibility (EMC) compared to electrical
the correct sequence in each cycle, the slot counters on all
the dynamic FlexRay message, the earlier it will be trans-
message and represents a slot in the static or dynamic seg-
signal transmission.
FlexRay nodes are incremented synchronously at the begin-
mitted, and the higher the probability of transmission given
ment. In the dynamic segment the ID corresponds to the
FlexRay communication is not bound by a specific topology.
ning of each static slot. Because of its guaranteed equidis-
a limited dynamic time segment length. The dynamic
priority of the FlexRay message. The individual bits of the
A simple, passive bus structure is just as feasible as an ac-
tant and therefore deterministic data transmission, the
FlexRay message assigned to the first minislot is always
status field specify the FlexRay message more precisely.
tive star topology or a combination of the two (Figure 3).
static segment is predestined for the transmission of real-
transmitted as necessary, provided that there is a suffi-
For example, the “sync frame indicator bit” indicates
The primary advantages of the active star topology lie in
time relevant messages.
ciently long dynamic time segment.
whether the FlexRay message may be used for clock syn-
possibility of disconnecting faulty communication branches
Following the static segment is an optional dynamic seg-
In the communication design it must be ensured that the
chronization.
or FlexRay nodes and - in designing larger clusters - the
ment that has the same length in every communication
lowest priority dynamic FlexRay message can be transmit-
After the header comes the so-called payload. A total of up
ability to terminate with ideal bus terminations when phys-
cycle. This segment is also organized into slots, but not
ted too – at least provided that there are no other, higher
to 254 useful bytes may be transported by one FlexRay
ical signal transmission is electrical.
static slots, rather so-called minislots (Figure 1). Communi-
priority needs. The designer of a FlexRay cluster must also
message. The trailer encompasses the header and pay-
To minimize failure risk, FlexRay offers redundant layout of
cation in the dynamic segment (mini-slotting) is also based
ensure that transmission of the longest dynamic FlexRay
load-protecting CRC (24 bit). Given a payload of up to 248
the communication channel (Figure 4). This redundant
on allocations and synchronous incrementing of the slot
message is even possible. Otherwise, the communication
useful bytes, the CRC guarantees a Hamming distance of
communication channel could, on the other hand, be used
counters on the FlexRay nodes.
design would not make any sense.
6. For a larger payload the Hamming distance is 4 [8].
Figure 2: Clock synchronization.
1/28
local clocks. At the end of the NIT, an offset correction is
Figure 3: Combined topology of passive bus and active star.
transmission during the NIT.
Figure 5: Example of communication flow in the dynamic time segment.
1/29
Figure 6: Structure of the FlexRay message with header, payload and trailer.
In Networking Issues: Achieving Objectives Rapidly with
Literature and links:
External Expertise
[1] www.destatis.de
In the year 2001, Vector Informatik was already offering
[2] www.bosch.com
the first product solution for the development of FlexRay
[3] Mayer, E.: Datenkommunikation im Automobil – Teil 2:
systems. In the meantime, developers can now obtain a
Sicherer Datenaustausch mit CAN im Automobil [“Data
comprehensive portfolio of products [9]. These include tools
communication in the automobile – Part 2: Reliable data
for designing, developing, simulating, analyzing, testing
exchange with CAN in the automobile”]. In: Elektronik Au-
and calibrating ECUs and distributed networks. DaVinci
tomotive 8/2006, pp. 34-37
Network Designer FlexRay gives the developer an environ-
[4] www.tttech.com
ment for efficiently designing network architecture and
[5] www.byteflight.com
communication relationships. Simulation, analysis and
[6] www.can-cia.org/can/ttcan
testing of FlexRay systems are performed with CANoe.
[7] www.vector-informatik.com
FlexRay, whose multibus concept enables simultaneous
[8] www.flexray.com
operation of FlexRay, CAN, LIN and MOST bus systems. For
[9] www.flexray-solutions.com
precise study of the FlexRay network’s system behavior in
[10] www.vector-academy.com
response to errors and disturbances, FRstress generates them on a channel in the FlexRay cluster. For direct access to internal ECU variables, the developer needs a special measurement and calibration protocol: XCP on FlexRay. In the context of the development of the active chassis system on the new BMW X5, BMW engineers implemented Vector’s measurement, calibration and diagnostic tool
Eugen Mayer (Graduate Engineer with Technical Teaching Certificate), after completing his vocational training to become a communications technician, studied electronics at the Technical College in Ravensburg/Weingarten, Germany, and studied electrical engineering and vocational teaching at the University of Stuttgart. Since 1999 he has been working at Vector Informatik where he is employed as a Senior Trainer.
Experience With Series Projects. Choose Proven FlexRay Solutions! Solutions for FlexRay
CANape. As the XCP-on-FlexRay Master, CANape measures and calibrates individual ECU parameters directly via FlexRay. Besides software, Vector also develops stacks for ECUs. FlexRay software components make it possible to interconnect applications with different bus or operating systems in an uncomplicated way. For hardware access to FlexRay buses, suitable bus interfaces connect to the USB, PCI and PCMCIA ports of a PC or notebook computer. The Vector Academy [10] can teach the basic knowledge needed to quickly become familiar with the diverse development activities related to ECU communication in the automobile. This knowledge is shared in the context of seminars on CAN, LIN, FlexRay and MOST.
Take advantage of our extensive experience with FlexRay series projects. Use Vector’s comprehensive product portfolio for your FlexRay networking: > Simulate, diagnose and test ECUs and networks
> Ensure advantages in both quality and time: Rely
with the sophisticated development environment
on professional support during development and
CANoe and the FlexRay interfaces
training.
> Profit from standardized ECU software. Vector software modules can be flexibly configured and
Get on board: www.flexray-solutions.com
easily integrated. Get FlexRay on the road – with series-proven tools, scalable modules and over 25 years of Vector networking know-how!
1/30
Vector Informatik GmbH | Germany · Austria · Brazil · China · France · India · Italy · Japan · Korea · Sweden · UK · USA | www.vector.com
Device
Wireless analysis in a multiprotocol CAN environment Timo Löw and Andreas Nacke (both Bomag), Holger Heit and Hans-Werner Schaal (both Vector Informatik)
I
n developing electronics for modern construction equipment, a large share can even be tested and simulated meaningfully on test benches. In later development stages, on the other hand, it is preferable to perform tests and trial runs under real conditions at construction sites or outdoor test sites. To avoid distracting the operator in the driver’s cabin with test equipment, a wireless interface has now been realized for the first time with the CANoe and CANalyzer development and analysis tools from Vector Informatik. Electronics developers at Bomag GmbH now use this interface to log the communication on various vehicle buses at a distance and analyze it. Quality requirements in earthmoving work and highway construction are continually growing with a simultaneous rise in cost and time pressure. Soil compaction and cost-, raw material- and energy-saving methods of road preservation and reconstruction are often only possible with intensive use of high-tech electronic functions. Bomag is the global market leader in the field of compaction technology. At its lead-plant in Boppard, this company – part of the Fayat Group – produces about 30 000 machines annually for soil, asphalt and garbage compaction as well as stabilizers/ recyclers. Today, a large share of the company’s expertise has its foundation in electronics. When it comes to networking technology, Bomag
66 1/32
machine with the most extensive electronics system and the most CAN nodes. First, it is used to improve and reinforce existing soil materials by mixing in lime, fly ash or cement, and secondly for milling, pulverizing and recycling existing materials in-place and locally.
Network cluster with multiple CAN buses Fig. 1: The electronics on the MPH 125 support efficient implementation in soil stabilization and recycling bases its work on the CAN bus standards of the automotive industry. Initially, the electronics concept was established on the large 10-t to 15-t machines, and it was then ported to the smaller machines. Since Bomag would like to have hardware and software components be reused as often as possible within the overall corporate group, the focus was on a modular concept. This also required standardization of development and test equipment across their business sites.
enables satellite-supported, large-scale compaction monitoring with seamless documentation of all parameters. In the future, radio networks will provide for data exchange between the machines driving in a group. The new type MPH 125 stabilizer/recycler – with an operating weight of 24.5 t and a power of 440 kW – is the
All Bomag machines of a given product line have the same control system, and they acquire their specific control functionality in end-of-line parameterization. Therefore, electronic developers mapped the machine’s modular product concept to a modular CANbased network cluster. CAN 1 – as the central BodyCAN bus – is connected to the most bus nodes. Its operation is based on the CANopen protocol, which enables the use of standard
Nothing works without electronics High-tech equipment and electronics can be found everywhere in the machines, from remote controls to drive-by-wire steering systems to the use of GPS. Sensors continually acquire the soil composition, and the display graphically indicates to the driver where compacting work is still needed. The GPS option
Fig. 2: The electronics concept reflects the modular layout of the machines
CAN Newsletter 2/2008
Fig. 3: J1939-specific interpretation of data in the Trace Window is performed with CANalyzer.J1939 automation components. Besides the vehicle’s main computer, the data acquisition unit of the front frame and I/O module of the rear frame, CAN 1 nodes also include control and display components in the cockpit. Conventional analog and digital sensors are interfaced to the data acquisition unit, e.g. hydraulic pressure sensors and fill level sensors. The I/O module on the rear frame is responsible for control of the variableheight rotor, lateral tilt angle and lowering cabin feature for transport purposes. It was possible to significantly reduce wiring cost and effort by interfacing controls to the bus; these include the CAN-bus-capable joysticks, LC displays and external switches. Bomag created an in-house development of a CANopen driving lever with friction brake. The powertrain bus is defined as CAN 2, and it interconnects the vehicle’s main computer, engine controller, steering and driving levers, including operator consoles on the right and left. Interesting here is that the J1939 and CANopen protocols are implemented in parallel on CAN 2. A special feature of the drive control system is load-limit control of the Deutz diesel drive, which provides for dynamic power distribution between higher milling power at low speed and lower milling power at high working speed as a function of soil composition. Besides CAN 1 and CAN 2 there may be a third
CAN 3 data bus, depending on how the MPH 125 is equipped. It incorporates an optional metering computer with auxiliary display and the necessary actuators for water injection. Similarly, CAN 3 is needed to interface to the metering system for bitumen emulsion and foamed bitumen.
Multi-protocol capable tools In electronics development, Bomag implements a number of software tools from Vector Informatik. The Stuttgart-based networking specialist offers tailor-made tools for all electronic development tasks, such as CANoe for network development and ECU tests, CANalyzer for analysis of bus data and CANape for calibrating ECUs. At the beginning of development, CANoe simulates the behavior of individual bus nodes or entire sub-networks (rest-of-bus simulation). Over the further course of ECU development, the models serve as a foundation for analysis, testing and integration of bus systems and ECUs. The C-like programming language CAPL and userdefined interfaces simplifies the user’s work. A special real-time configuration significantly improved realtime capabilities even further, first by using separate PCs for rest-of-bus simulation and test execution, and second by graphic control/ evaluation; this yielded the high performance of a component HIL tester.
CAN Newsletter 2/2008
67 1/33
The CANalyzer analysis tool offers numerous functions for bus analysis. They range from tracing the bus data traffic to displaying signal values, performing statistical evaluations of messages, busloads and disturbances, and finally targeted generation of specific bus disturbances. CANape is used in the calibration of electronic ECUs. All important variables and parameter sets can be modified and visualized in real time. Helpful in conjunction with the de-
Besides supporting CAN, the tools also support the LIN, FlexRay and MOST buses as well as the higher level protocols J1939, J1587, NMEA2000, ISO11783 and CANopen. In the case of Bomag, CANape and the CANalyzer/CANoe options for J1939 and CANopen are used. Protocol-specific extensions of the tools relieve the user of the need for detailed training in the J1939 or CANopen protocol; this avoids faulty interpretations of CAN frames. Last but not least, another important re-
now made it possible to establish contact with the DUT by an extension via a modified WLAN system. So the transceiver cable between PC and CAN bus is quasi removed and replaced by the radio pathway. Noteworthy here is the fact there are no significant compromises with regard to accuracy or measurement requirements. In implementing the extension, special attention was given to satisfying requirements for correct timing in data transmission, low latency times and time-syn-
Fig. 4: The extended WLAN tunnels the CAN messages, including time stamp, via a TCP/IP interface, thereby enabling time-conformant representation of the data velopment of GPS applications is CANape Option GPS, which supplements the system with visualization of the momentary vehicle positions on an electronic map. The universality of Vector tools is paying off at Bomag by helping it to master the complex challenges of working with multiple buses, and in particular the J1939/CANopen multi-protocol environment. The consistently applied database concept is an important pillar for the efficiency of the development tools. All members of the tool chain access the same data set, so that it is possible to save all data consistently without unnecessary redundancies or sources of error. Fitting for the bus systems used, the relevant databases of the network description are either already integrated or automatically generated to match the network configuration.
quirement in the analysis of muli-bus/multi-protocol environments is that a uniform time base must always be present as a foundation for analyses.
No need for an ‘umbilical cord’ What has been difficult for Bomag electronics developers to achieve until now is time-synchronous analysis of the measurement data during the field tests mentioned in the introduction without having to be passengers in the machine. They were only able to examine the logged data afterwards, but not during a test. For these and similar cases, there is now a technically mature WLAN solution from Vector: While previously it was absolutely necessary to maintain physical contact to the bus system being analyzed when working with the tools, the specialists from Stuttgart have
chronous display of the data on the PC. The CAN messages – together with their time stamps – are tunneled via a TCP/IP connection, so that the time stamps provided with the messages can serve as reference times for CANoe and CANalyzer.
‘Drilled out’ WLAN solution This solution offers some key advantages compared to the capabilities of a simple CAN/WLAN bridge. Only a bridge header is necessary for this setup. Sufficient as a host is a WLAN-capable laptop/ notebook, which maintains the connection via standard on-board resources and WLAN. The “probe” on the DUT that is responsible for converting from CAN to WLAN sends the messages in strict and chronologicallycorrect order by considering the time stamps originally
logged on the bus, which would not be possible via a CAN-WLAN-CAN bridge. During machine operation at the construction site, the Bomag electronics developers can measure, observe and evaluate without a hard wire connection to the machine.
Summary and outlook This example from the commercial vehicle sector shows that there are interesting and demanding challenges outside of the realm of automotive electronics for luxury cars, challenges that can only be handled by complex network clusters and high-performance development and analysis tools. The universality of Vector solutions pays off here. The tools enable analyses and simulations directly on the higher layers of J1939 and CANopen. The use of multiple buses or simultaneous use of different protocols on the same bus do not present any problems. The tools always ensure correct timing with the same time base in data acquisition and evaluation – even in the case of wireless communication. The Bomag developers already have their sights set on the next WLAN project involving automatic, multiday durability tests. Thanks to a WLAN connection, the electronics developers are able to continually observe events on the relevant bus systems with the mentioned tools. That can be done from the office or via the Internet, e.g. from home during the weekend. Sources: Fig.1 and 2: Bomag GmbH, Fig. 3 and 4: Vector Informatik GmbH
holger.heit@ vector-informatik.de
[email protected] andreas.nacke@ bomag.com hans-werner.schaal@ vector-informatik.de
Ethernet Control Units Develop them efficiently ... with the Automotive Ethernet solutions from Vector
Our solutions support the specific physical layer in automotive as well as the protocols SOME/IP, AVB, DoIP, etc. > Tools for simulating, analyzing and testing of Ethernet networks and controllers – also together with other vehicle bus systems > Interfaces for undistorted access to Ethernet networks > Embedded Software with small footprint, for automotive use
> Universal control unit for small production runs, evaluation and development – complete with AUTOSAR basic software > Training on Ethernet technologies in the automotive domain More information & downloads: www.vector.com/ae
Benefit from over 25 years’ experience in automotive electronics. Reference Chart Automotive Ethernet Useful know-how, free-of-charge, order now: www.vector.com/eth-poster
68 1/34
CAN Newsletter 2/2008 Vector Informatik GmbH | Germany · Austria · Brazil · China · France · India · Italy · Japan · Korea · Sweden · UK · USA | www.vector.com
complex field tests to validate driver assistance systems. Guiding such complex systems to market maturity requires numerous trials and driving tests as an indispensible part of the development process. The assistance systems must repeatedly prove their reliability under all conceivable constraints and conditions (Figure 1). In the pursuit for improved efficiency in a current ACC project, the need arose for time-synchronous wireless logging of CAN data, both of the vehicle under test and the target vehicle involved in the traffic event. In particular, time-synchronous logging of position and speed information were of great interest in evaluating and documenting during the test drives, since they enable real-time visualization from a
Acquiring Bus Data Wirelessly from Multiple Vehicles
control center located on the perimeter of the test track. Evaluating and optimizing the control algorithms requires
Figure 2: Driving robots handle all necessary functions such as accelerating, braking, steering, etc., in reliable validation of driver assistance systems.
knowledge – as precise as possible – of relative distances, speeds, transverse accelerations, etc. Where were the vehi-
Top-notch Precision Despite the “Air Interface”
cles exactly? What was the latency time of the assistance
Jürgen Luther and his colleagues in Research and Advanced
system’s reaction? And even more important: does the sys-
Development are responsible for establishing new test
tem only react when it should react?
methods for assistance systems throughout Daimler and for providing the necessary measurement equipment for
Driving Robots Assure Reproducible Maneuvers
test trials. The driving robots that are used are able to drive
Validation of assistance systems involves an enormous
trajectories based on a differential GPS signal with a max-
amount of technical effort. Fractions of seconds are involved
imum lateral deviation of less than five centimeters and a
in deciding the success or failure of actions and reactions of
time deviation in the 100 millisecond range. In ACC tests,
In the past, analysis of vehicle communications has generally been limited to a single vehicle. This situation is changing
the vehicles, and driving maneuvers must be absolutely re-
this makes it possible to have two vehicles with different –
with the development of new driver assistance systems, and it is of primary importance to Car2x technologies. A current
producible. So, it is not only out of concern for safety that
sometimes quite fast – approach velocities drive past one
project – involving validation of an ACC system at Daimler AG – represents the first time that bus data from two test
Daimler is utilizing driving robots instead of human test
another on predetermined paths with an extremely small
vehicles have been logged time-synchronously with wireless technology and displayed in real-time on the display of a
drivers (Figure 2). These robots can handle all necessary driv-
lateral gap of just ten centimeters. Right and left lane-
ing functions such as accelerating, braking, steering, etc.,
changing maneuvers are also tested with different veloci-
stationary control station.
As specialized bus systems such as LIN, MOST and FlexRay
Even when just one vehicle is considered, validation faces
began to supplement existing CAN networks, the need
many challenges [1]. It is no longer sufficient to consider
arose for development tools that could handle multibus
each vehicle separately; rather, it is necessary to consider
systems. One of the key objectives – that is still relevant
CAN bus information and measured values from all of the
today – was to use one analysis tool to acquire and display
vehicles involved.
time-synchronous messages from different systems and
The assumption that has been made until now is of a wire-
bus branches networked via gateways.
bound physical connection to the mobile computer travel-
and they even execute the tightest of pass-by maneuvers
ties and gaps. Until now, Daimler devel opers lacked a
and “near crashes” precisely and without any emotion.
method for establishing a time reference between the dif-
ing in the vehicle that is by its nature restricted to one vehiNew Territory: Acquiring CAN Data from Multiple
cle. The “air interface” is a nearly insurmountable obstacle
Vehicles Timesynchronously
to causal and time-accurate representation of communi-
Current developments in the area of driver assistance sys-
cation involving multiple vehicles. So far, the fulfillment of
tems are leading to impressive growth in functionality. They
key preconditions for realizing the dream of “untethered”
range from simple convenience functions to safety-related
bus data acquisition has been lacking.
systems such as braking assistants and intelligent adaptive
1/36
cruise control (ACC). These systems utilize sensors based
Challenge of Synchronous Measurement Despite the “Air
on technologies such as microwave radar, infrared light or
Interface”
ultrasound, and they still operate autonomously from the
Measurement technology specialists at Daimler AG are
perspective of a single vehicle. Now, development and test-
tackling issues related to synchronous wireless measure-
ing departments are, for the first time, being confronted
ment data acquisition. A traditional forerunner in the de-
with a situation where multiple vehicles are involved in events.
velopment of innovative technologies, Daimler conducts
Figure 1: Typical test scenarios with vehicle under test and target vehicle, in which precise data s ynchronism is required: A – Sudden swerve into lane, e.g. for ACC scanning and ranging B – Close passing maneuver with hard braking, e.g. in brake assistants C – Close encounter in cross traffic as benchmark for greatest precision demand
1/37
Acquiring Bus Data Wirelessly from Multiple Vehicles
For some time now, IP has also made an entry into the
mission times (delays) are computed based on the response
maximum time deviations of under five milliseconds were
vehicle. They could not be displayed together in the Trace
automotive field. For example, flashing is done over IP via
messages. This enables correction for the deviation (offset)
attained, which is more than sufficient for most applications.
Window. A time deviation of just 5 milliseconds between
one ECU to flash multiple ECUs in different bus systems.
in the next pass and control of the clock rate (drift), i.e. accel-
Using WLAN from the perimeter of the test track, Jürgen
the two sets of vehicle data at a speed of 20 m/s would still
Also, developers encounter IP in WLAN form, because CAN
erating or slowing the oscillator. With progressive iterations,
Luther and his colleagues now conveniently observe, evaluate,
represent a spatial offset of 10 centimeters, which is the
messages can be sent over WLAN/ Ethernet when packed
this approach converges toward synchronization. In this
document bus traffic during the precise and coordinated
required precision of the driving maneuver.
in Ethernet packets. Remote CAN is desirable wherever
method, there is an agreement on which of the two times will
maneuvers of the vehicles, and they can make immediately
CAN bus systems are difficult to access or are mobile, such
be used as the reference, and the events of the other bus sys-
qualified assessments on the success of a test trial (Figure 4).
CAN over IP over WLAN ...
as in remote control or remote monitoring of engine dyna-
tem are correctly mapped to this reference. This approach
Utilizing the CANoe test tool – widely used in the automo-
mometers, HIL tests or wireless acquisition of CAN data [2].
succeeds even in the case of astonishingly imprecise clocks,
From Intelligent Vehicle to Car2x Participant
ferent CAN buses of the vehicle under test and the target
tive industry – and the Option .IP available for it, Daimler
and in principle it can be applied to interface hardware pro-
The pilot application at Daimler clearly shows the direction
worked together with Vector to come up with a solution for
IEEE 1588 Synchronizes Clocks
duced by any manufacturer, provided that the latest ver-
in which the focus of testing is moving. Advanced develop-
wireless and synchronous bus data acquisition of multiple
In cooperation with measurement technology specialists at
sion of CANoe .Ethernet or CANalyzer .Ethernet is used.
ment of today’s assistance systems in the direction of
vehicles. This solution gives Daimler employees the ability to
Daimler, Vector extended the CANoe .Ethernet tool by add-
For a general explanation and overview of the principles of
Car2x technologies has long begun. If one assumes that
acquire, save and visualize the CAN messages of both vehicles
ing the necessary functions for ACC tests at Daimler. The
this method, see [4].
traffic density will continue to grow, intelligent vehicle com-
with a common time base (Figure 3). CANoe .Ethernet is
following solution approach was taken: If one makes the
an extension of the standard version of CANoe with addi-
theoretical assumption that precisely synchronized clocks
Extended WLAN Range
ulate the flow of traffic, better utilize roads and improve
tional Ethernet-specific functions. For a long time now, the
are available as time references in each of the two vehicles,
Another problem had to be resolved as well – the problem of
traffic safety. One indication of this is that the “CAR 2 CAR
standard version has enabled efficient study of multiple
all data packets can be sent out with highly precise time
limited WLAN range. When commercially available WLAN
Communication Consortium” [5] is already working on
vehicle buses beyond gateway limits. It let’s users display
stamps and these time stamps can be used to clearly trace
antennas are used, range is limited to a maximum of 100 to
standardization that will enable future communication
information acquired with high precision in real time during
the data chronologically at the receiving end. However, in
300 meters, depending on whether the antenna is located
between vehicles via Wireless LAN (WLAN) throughout
test drives or stationary tests and analyze logged data at
practice this does not succeed without additional mea-
inside or outside the vehicle. These values were too low for
Europe.
their convenience afterwards.
sures, since synchronized clocks will drift apart from one
test track use, so a special WLAN antenna with a high an-
At automotive OEMs and suppliers, vehicle tests are in-
The IP program variant of CANoe, on the other hand, is
another.
tenna gain of 15 dBi was used, which increased range to
creasingly being extended to cover more than one vehicle.
used in development, simulation and testing of embedded
The primary focus here is on re-synchronizing the clocks
1200 meters. These “large” antennas, which are 4 centime-
The potential number of future Car2x applications and test
systems in the IP area. This is different than in the office
and packing the messages with original time stamps from
ters in diameter an 80 centimeters in length, are mounted
scenarios is enormous. Vehicles further ahead in traffic can
communication field, embedded systems involve distribut-
the remote CAN buses into WLAN packets. The method
to the car roof with magnetic feet; they also signal to all
send warnings about hazardous situations to vehicles that
ed control loops that can now be served by an IP bus sys-
used for clock synchronization comes from an internation-
human test drivers that robotic vehicles are in use.
follow. Intersection assistants can signal that a vehicle is
tem instead of CAN or LIN. Under such constraints, CANoe
ally recognized procedure standardized in IEEE 1588 [3]
Thanks to CANoe’s flexible and open concept – as well as the
hidden behind a building at a corner, indicating its position,
can also be used to test and simulate such entities as IP
and designed for local networks such as Ethernet. While a
seamless teamwork of the two companies – Vector devel-
driving direction and speed as shown in scenario C of Fig-
nodes and gateways to graphically display and analyze the
reference clock, defined as the ‘Master clock’, supplies the
opers were able to make the necessary modifications and
ure 1. This could be supported by beacons (also known as
data in display windows.
‘Slave clocks’ with synchronization messages, the trans-
adaptations quickly. The results surpassed even the initial ex-
Road Site Units).
pectations of the customer. Despite the critical air interface,
Test equipment that has been used so far for data acquisi-
munication will even become an absolute necessity to reg-
tion in a single vehicle is reaching its ultimate limits when faced with such development challenges. At the same time, the topics addressed here are of central importance to a large group of developers. In the future, typical timing issues must be resolved for multiple vehicles, e.g. in blind spot monitoring when the bus system of the lanechanging vehicle gets the information that it must not pull out into the neighboring lane. Developers will have to become accustomed to the idea of log-ging and processing data with a uniform time base for multiple vehicle domains. This will require forging many new paths, and special attention must be given to the air interface in particular. The roles of Ethernet, WLAN and IP will also grow in importance in the automotive industry. To satisfy future Car2x requirements, Vector is continually advancing the development of CANoe in collaboration with its users. The next step is to support the IEEE 802.11p standard, which is important in establishing WLAN in vehicles. Figure 3: Time-synchronous data transmission to CANoe .Ethernet over WLAN with a maximum deviation of 5 milliseconds.
1/38
Figure 4: CANoe Ethernet simulates a traffic scenario based on the example of a received skidding warning.
1/39
Translation of a German publication in Elektronik automotive, 7/2010 Image rights: Initial Screen: Vector Informatik GmbH Figure 1: Vector Informatik GmbH, based on documents from Daimler AG Figure 2: Daimler AG Figure 3: Daimler AG and Vector Informatik GmbH Figure 4: Vector Informatik GmbH Literature: [1] H. Hurich, Wolfgang, H., Luther, J., Schöner, Dr. H.-P.: Koordiniertes Automatisiertes Fahren zum Entwickeln, Prüfen und Absichern von Assistenzsystemen [“Coordinated Automated Driving in Developing, Testing and Validating Assistance Systems”], 10th Braunschweiger Symposium AAET 2009 [2] Löw, T.; Nacke, A.; Schaal, H.-W.: Für schweres Gerät – Drahtlose Anbindung von Entwicklungs- und Analysewerk zeugen [“For Heavy Equipment – Wireless Interfacing of Development and Analysis Tools”]. Elektronik automotive 2008, Issue 2, pp. 38ff. [3] Introduction to IEEE 1588: http://ieee1588.nist.gov [4] Wiebel, Prof. Dr. H.: Uhren mit IEEE 1588 synchronisieren [“Synchronizing clocks with IEEE 1588”], Bulletin SEV/ VSE 2004, Issue 4, pp. 35ff, www.ines.zhaw.ch/fileadmin/ user_upload/engineering/_Institute_und_Zentren/INES/ IEEE1588/Dokumente/Fachartikel_IEEE1588_02.pdf [5] CAR 2 CAR® Communication Consortium: www.car-tocar.org Links: Homepage Daimler AG: www.daimler.com Homepage Vector: www.vector.com Product Information CANoe .Ethernet: www.vector.com/ vi_canoe_ethernet_en.html Information Vector Solutions for Car-2-x: www.vector.com/ car2x Jürgen Luther, Daimler studied Physical Technology at the Technical College of Lübeck. Mr. Luther is a scientific assistant in Research & Advanced Development at Daimler AG and is responsible for support and ongoing development of new testing methodology with driverless robotcontrolled vehicles.
Hans-Werner Schaal, Vector studied Communications Engineering at the University of Stuttgart and Electrical & Computer Engineering at Oregon State University in Oregon, USA. Mr. Schaal is Business Development Manager for the Open Networking product line at Vector Informatik GmbH. Prior to this, he worked in various industries as development engineer, project leader and product manager in the test tools area for several network technologies.
1/40
Requirements of an IP Development Tool
used LVDS technology [1], [4], [5]. BroadR-Reach will be
First, known requirements of previous bus systems still ap-
licensed by other producers [6].
ply to the development tool. Initially, what is required is a
An example of a camera system network is shown in Figure 1
detailed protocol analysis with stimulation option that ex-
together with potential measurement points. As an alter-
tends to script-based testing with automatic generation of
native, it would also be possible to connect all cameras
test reports. The user also expects that the market-proven
directly via a switch. As in bus systems used so far in the
multibus capability will of course be extended to include
motor vehicle, the data traffic must be observed, analyzed
Ethernet and IP, so that dependencies between events on
and compared time-synchronously at various points in the
different bus systems can be studied. Currently, for exam-
network. Therefore, the measurement hardware must ini-
ple, there is interest in correlation between LIN and CAN,
tially support the current bus physics (e.g. BroadR-Reach),
and in the future interest will be between CAN and IP.
but must also be open to future physical layers. Desirable
As previously, in protocol analysis the user needs easy sym-
are multi-channel taps via tee-couplers, which disturb the
bolic access to all relevant application signals as well as the
system network as little as possible in monitoring. The
ability to further process them in any desired way – logical-
tee-coupler should also be capable of injecting errors to
ly and graphically. However, there will also be new require-
validate system functionality. Beyond analysis tasks, stim-
ments, which on the one hand are imposed by the bus phys-
ulation or even simulation of entire sections of the network
ics and on the other by the wide variety of IP protocols. The
is also required (remaining bus simulation). This poses cer-
article explains – based on the current camera example and
tain challenges on the measurement hardware.
four other application areas of IP and Ethernet in the motor
In the camera application, there are heightened require-
vehicle – how these measurement tasks present them-
ments related to time synchronization and Quality of Ser-
selves in product development departments from the per-
vice (QoS) [4]. They should be addressed by protocol exten-
spective of the system manager, and which special require-
sions of the Audio Video Bridging standard (AVB) [7]. Now
ments result for the development tool.
that manufacturers have appeared to reach agreement on the bit transmission layer (OSI Layer 1), standardization is
1. Camera – Ethernet as System Network
IP and Ethernet in Motor Vehicles Challenges for the Development Tool, Illustrated by Today’s Applications Until just a few years ago, the prevailing opinion was that Ethernet would never be used for in-vehicle applications, with the exception of diagnostic access. Soon, however, camera-based driver assistance systems will be the first applications
being sought in higher layers as well for cost and testing
A camera-based driver assistance system at BMW will be
reasons.
the first production implementation in the motor vehicle to
If only because of the different protocols used in the camera
utilize IP and Ethernet as the system network in the vehicle [1].
application, there are new requirements for the measure-
OEMs and suppliers will use the new BroadR-Reach physical
ment software, so that any desired signals from the pay-
layer to save on weight and costs compared to currently
load of the various, some quite complex, protocols can be
to utilize Ethernet technology as a system network. This presents new challenges to automotive OEMs, suppliers and development tool producers, because the Internet Protocol and Ethernet represent a new network technology for motor vehicles. Nonetheless, many of the issues can already be solved.
After the debut of the CAN bus in the Mercedes S-Class in
recent years, other use areas have increasingly been dis-
1991, the LIN, MOST and FlexRay bus systems also became
cussed in automotive research and development depart-
established in the motor vehicle. Today, CAN continues to
ments, because Ethernet’s, scalable bandwidth and flexibil-
be used in automotive network architectures in all domains
ity spoke strongly in its favor. Nonetheless, a suitable and
(from powertrain to body). LIN bus technology is ideal for
economical wiring technology was lacking for the motor
simple and cost-effective data exchange of noncritical sig-
vehicle.
nals in the convenience area. Where bandwidths and real-
Currently, the main drivers for Ethernet usage in the vehicle
time requirements run into limitations, CAN is replaced by
are camera-based driver assistance systems. In camera
FlexRay or MOST – in cases where it is economically justifi-
applications in the vehicle, LVDS technology (Low Voltage
able. In today’s vehicles, one often finds all of the named
Differential Signaling) has been used until now. The shield-
bus systems, segmented and networked via gateways.
ed cable that is generally used there does indeed assure electromagnetic compatibility, but it is expensive by indus-
1/42
Motivation for Ethernet
try measures, and it is very impractical to install in the mo-
Ethernet has long been an established standard technolo-
tor vehicle. Most recently, a physical layer is available that
gy in office communications, industrial engineering (ODVA
offers full-duplex transmission at 100 Mbit/s on a CAN-like,
standards, Ethernet/IP and ProfiNet) and in the aerospace
two-wire cable (unshielded twisted pair), and in the opinion
industry (AFDX®). In the automotive field, Ethernet had
of various publications it is suitable for use in the motor
already proven itself in the vehicle for diagnostic access. In
vehicle [1], [2], [3].
Figure 1: Reliable analysis of camera-based driver assistance systems requires monitoring the data traffic at multiple points of the Ethernet network, ideally via “tee-couplers” with as little time offset as possible and with a common time base.
1/43
IP and Ethernet in Motor Vehicles
side as well. Relevant protocols are ISO 13400 and IPv4,
or XCP on CAN). However, if Ethernet makes its way into
and possibly IPv6 as represented in Table 1.
the vehicle in the near future, measurement and calibration over XCP on Ethernet would also be very attractive in pro-
3. Electric Refueling Station – Smart Charging
duction vehicles due to its significantly higher measure-
Smart Charging goes far beyond simply plugging into a
ment data rates.
household electrical outlet. The electric vehicle to be
Table 1: IP protocols of automotive applications mapped to the OSI reference model (left-side columns) including administrative functions (right-side columns): Both new protocols (red) and those known from office communications (gray) are used.
5. WLAN and Car2x
station. Charging processes do not simply start up; first,
Car2x is understood as the external communication be-
the need to charge is communicated. Delaying individual
tween vehicles and the infrastructure. Applications range
charging processes by fractions of a minute can avoid over-
from convenience functions to traffic flow optimization
loads of the grid. The connected vehicles can also be used
and heightened traffic safety (driver assistance systems).
as storage media, and electrical provider billing can be
The technology is already in pre-production development,
automated.
and standardization is quite advanced. It is IP-based, and
This is made possible by communication between the vehicle
the IEEE 802.11p standard is used as the physical layer.
and charging station over Ethernet on IP based protocols,
From the perspective of the systems manager measure-
in standardization defined in the ISO 15118 standard. The
ment technology interest in Car2x applications extends to
charging station communicates with the grid and the vehicle
beyond the boundary of the individual vehicle to a number
here. For the systems manager at the automotive OEM,
of other vehicles and RSUs (Roadside Units) in the near en-
communication between the car and the charging station
vironment. The ECU to be evaluated not only communi-
is quite important. A detailed analysis and validation of the
cates with bus systems located in the vehicle, but also over
protocols is absolutely essential to safeguard the charging
the air interface with other traffic participants. The devel-
process. The development tool must also support these
opment tool must therefore support these IP-based stan-
protocols (Table 1, “Smart Grid” column).
dards as well. In addition, other requirements arise in the
presented and manipulated according to the application.
2. Diagnostic Access
The “Audio/Video” and “Control Communication” columns
Using “Diagnostics over IP” (DoIP) technology, it is possible
4. Calibration, Debugging, Flashing
of Table 1 (based on [7] and Vector) show the protocols
to centrally flash all ECUs connected to the various bus sys-
For many years now, Ethernet has been used with the XCP
New Variety of Protocols for Applications and
used for AVB. There are also protocols for bandwidth reser-
tems via high-performance Ethernet access (Figure 2).
measurement and calibration protocol to calibrate, debug
Measurement Tool
vation and other network management protocols (Table 1,
System development at the OEM must validate this ser-
and flash ECUs in development. However, Ethernet access
Table 1 summarizes, by examples, the various application-
four columns on the right). These and other protocols listed
vice. Since an ECU is used as the gateway, not only is there
is no longer provided in the production vehicle for cost rea-
dependent transmission layers and protocols, which the
in the table were added based on the application cases
great interest in analyzing the transmission of diagnostic
sons. Therefore, calibration and reprogramming are current-
development tool must support simply based on cases
considered below.
data in the various connected bus systems, but on the IP
ly performed using the existing working protocol (e.g. CCP
occurring so far. Some of the protocols used in the area of
high-frequency range (WLAN in the 5 GHz band).
Figure 2: In validation of DoIP at a gateway, it is important to represent the data traffic both on the DoIP side (to left of the gateway) and on all connected bus systems (to right of the gateway). Ideally, all messages of all networks are transmitted with a common time base.
1/44
charged is connected to the electrical grid via a charging
Figure 3: CANoe .Ethernet supports the development, s imulation and testing of embedded systems that communicate over IP or Ethernet.
1/45
IP and Ethernet in Motor Vehicles
office communications are found here, while many others
Outlook for Vehicle Networks
face options (Figure 4). In the simplest Case 1, it works with
Vector´s know-how especially for Smart Charging:
may be omitted, and certain others are added. The table
In-vehicle use of CAN is expected to continue much longer
any network cards existing on a Windows computer. If
www.vector.com/vi_electric_vehicles_en.html
shows in light gray those protocols that can be adopted
than ten years into the future, while all of the other bus
BroadR-Reach is used, or if it should also be possible to in-
from office communications. Those added due to the new
systems discussed here will be used for at least ten years.
ject errors, then in the future a device of the new VN56xx
automotive application are shown in red.
Nonetheless, applications will increasingly tend towards
product line could be used as a hardware interface (Case 2).
The measurement system has the task of resolving all rele-
the use of IP and Ethernet due to growing requirements
This significantly improves time synchronism between the IP
vant protocols and placing all network events in a causal
with regard to bandwidth, flexibility and cost-effective-
channels and with other bus systems. If real-time behavior
relationship (correct sequence). Here it is desirable to be
ness. In upcoming years, multiple bus systems networked
is required, CANoe .Ethernet could be operated together
able to represent all bus domains with a common time
over gateways will be found just as they now exist. Ethernet
with the real-time hardware VN8900 in the future, which
base and with sufficient precision.
and IP will simply be added. As in the case of the camera
of course works seamlessly with the VN56xx interface
application, new challenges will arise on all protocol levels
hardware (Case 3).
Validation of IP Production Projects
in future IP applications, yet it will be possible to overcome
As the evaluation of the above application cases demon-
them with suitable development tools.
strates, causality or even time analysis extending over mul-
AFDX® is an Airbus’ registered trademark Hans-Werner Schaal (Graduate Engineer) is Business Development Manager in the areas of Automotive Ethernet, Car2x and open CAN protocols such as J1939 and ISO11783 at Vector Informatik GmbH.
Translation of a German publication in Elektronik automotive, 4/2012
tiple bus systems make it difficult to impossible to utilize
Outlook for IP Development Tools
standard Ethernet tools from office communications for
In the automotive field, development tools conceptualized
Literature:
multi-bus applications in the vehicle. Ethernet in the office
for IP continue to be advisable. On the one hand, they must
[1] Bogenberger, R., BMW AG: IP & Ethernet as potential
field is not the same as Ethernet in the automotive field.
support all protocol levels, but on the other they must also
mainstream automotive technologies. Product Day Hanser
The same applies to the specific Internet protocols that are
fit into the typical industry tool landscape. Suppliers are es-
Automotive. Fellbach, 2011.
used. They differ in type and complexity, depending on the
pecially called upon to provide suitable development tools
[2] Neff, A., Matheeus, K, et al.: Ethernet & IP as application
application – as significantly as the requirements of the
for validation of product development projects at the OEM.
vehicle bus in use scenario of camera-based driver assis-
physical layer differ.
Naturally, this includes support and ideally tool producer
tance systems [German lecture]. VDI Reports 2132, Elec-
A suitable engineering format is important in representing
assistance product introduction as well.
tronics in the motor vehicle. Baden-Baden, 2011. pp. 491-
the signal structure of the protocols in the development
Today, Option Ethernet, which is based on the proven
495.
tool and in generating the embedded code. DBC format is
CANoe simulation and test tool from Vector Informatik, al-
[3] Streichert, T., Daimler AG: Short and Longterm Per-
the commonly used engineering format for CAN, while FIBEX
ready covers the described requirements for an Ethernet
spective of Ethernet for Vehicle-internal Communications.
is commonly used for FlexRay. However, the DBC format is
development tool. With its wide variety of Ethernet-specif-
1st Ethernet & IP @ Automotive Technology Day, BMW,
no longer adequate as a database format for the new
ic functions and multibus capability, CANoe .Ethernet can
Munich, 2011.
Ethernet and IP based system network. From the perspec-
help to reduce development time, allowing valuable re-
[4] Nöbauer, J., Continental AG: Migration from MOST and
tive of tool suppliers, it would be helpful if OEMs could agree
sources to be used more effectively on the application side
FlexRay Based Networks to Ethernet by Maintaining QoS.
on a common engineering format. Suitable candidates would
(Figure 3). CANoe .Ethernet for automotive network devel-
1st Ethernet & IP @ Automotive Technology Day, BMW,
be FIBEX 4.0 and AUTOSAR System Description formats.
opment offers the same development convenience as is al-
Munich, 2011.
Experience from other industrial fields indicates that tool
ready the standard for the established CAN, LIN, MOST
[5] Powell, S. R., Broadcom Corporation: Ethernet Physical
producers would provide suitable development tools for
and FlexRay bus systems. The development tool exhibits a
Layer Alternatives for Automotive Applications. 1st Ether-
analysis and code generation soon thereafter.
high degree of scalability and basically offers three inter-
net & IP @ Automotive Technology Day, BMW, Munich, 2011. [6] NXP Develops Automotive Ethernet Transceivers for In-Vehicle Networks November 09, 2011, www.nxp.com/ news/press-releases/2011/11/nxp-develops-automotive- ethernet-transceivers-for-in-vehicle-networks.html. [7] Völker, L., BMW AG: One for all, Interoperability from AUTOSAR to Genivi. 1st Ethernet & IP @ Automotive Technology Day, BMW, Munich, 2011. Image rights: Vector Informatik GmbH Links: Vector Solutions for IP and Ethernet: www.vector.com/vi_automotive_ethernet_solutions_en. html
Figure 4: CANoe .Ethernet with scalable hardware interfaces and optional real-time support
1/46
Product information CANoe .Ethernet: www.vector.com/vi_canoe_ethernet_en.html
1/47
Figure 1: Along with protocols familiar from the field of office communications such as UDP, TCP and IP, protocols specially optimized for automotive use are also used. They are described in ISO CD 17215-1.
Second, developers must utilize new, relevant filtering
analysis and testing purposes; their undesirable effects are
strategies to process the enormous quantities of data. The
explained, and it is shown how these effects can be mini-
situation will be further intensified by transmission rates in
mized.
the gigabit per second range, which are already on the wish
Challenge of Ethernet Use in the Automobile
Limitations of Previous Solutions
known as RTPGE (Reduced Twisted Pair Gigabit Ethernet),
A natural approach to analyzing an Ethernet network is to
is already in development.
use an additional port (monitor port) at the implemented switches in the system (mirroring). All packets received
Flexible Interfaces and Software Tools Simplify ECU Development
Minimizing Effects of the Interface on System
from the switch are forwarded at this monitor port. This
Already this year, Ethernet will be used as a system network in the first production vehicles. Therefore, the next step is to
Performance
provides access to the arriving data packets, yet these data
Unlike in a bus system, special measures must be taken to
packets are not interrelated by a common time reference
avoid measurement effects on the system. On the one
– there is no time stamp. Moreover, often only valid packets
hand, developers must consider testability early in the sys-
are forwarded to the monitor port, which makes error
tem design (Design-to-Test). On the other hand, the tool
analysis difficult. Furthermore, for cost reasons no addi-
producer must minimize the effects of the interface. Pre-
tional monitor port is provided at the switch for mirroring
sented in the following are various measurement setups for
in the production system. [4].
integrate Ethernet with established technologies in the automotive industry: CAN, FlexRay, LIN and MOST. Functional development tools exist for them, which make it easy for developers to analyze heterogeneous networks. On the Ethernet side, however, only standard tools from office communications exist, but they do not support the special physical layers and IP protocols of the automotive world. Therefore, development and test tools are urgently needed that can be used to analyze and test existing bus systems together with Ethernet networks. But what would be the exact requirements of these tools?
It is already state-of-the-art technology to transmit cam-
Challenges of an Automotive Ethernet Test Solution
era images in vehicles at 100 MBit/s over a cost-effective,
The use of Ethernet in motor vehicles will require rethinking
unshielded twisted pair connection. This technology is
by developers and test engineers. First, efforts must ad-
known as BroadR-Reach, which is standardized by the
dress the issue of how to obtain a clear domain architec-
OPEN Alliance SIG consortium [1]. The next objective is to
ture (Figure 2). In this architecture, the backbone is no lon-
use Ethernet as a network for infotainment and driver as-
ger a bus system, but rather it is implemented as a switched
sistance systems by 2015. Some OEMs predict that Ether-
network with multiple full-duplex connections. When using
net will become a backbone technology starting as early as
it to implement real-time critical applications, synchroniza-
2018 [2]. As described in a number of professional articles
tion technologies are required on higher protocol layers above
[3, 4], Ethernet offers flexibility, scalability and cost advan-
the physical layer (OSI layer 1), e.g. AVB (Audio Video Bridg-
tages in automotive use, especially in combination with
ing, Figure 1). Analysis requirements are also growing for
certain Internet Protocols (Figure 1, [1]). Moreover, it offers
the new architecture. For example, if the developer wishes
the opportunity to enrich the proven automotive develop-
to simultaneously analyze all data traffic on the backbone,
ment process with methods from the IT world.
access must be synchronized on all path branches (Figure 2, a, b, c, d).
1/48
lists of OEMs. A physical layer that is suitable for this,
Figure 2: Potential domain architecture of future IP networks in the motor vehicle. To be able to analyze all Ethernet packets, the analysis software must access all Ethernet paths synchronously.
1/49
Challenge of Ethernet Use in the Automobile
>>It must be possible to use the analysis and simulation
If no additional port is available at a given switch, an addi-
For an inactive interface a transparent behavior is also im-
Important Properties of a Flexible Interface/Software
tional switch can be inserted in an existing connection. This
portant. If the interface hardware is installed in the vehicle
Combination
additional hop is not transparent, however, and it causes a
for a test drive, for example, the interface must autono-
The described measurement setups illustrate how the
delay over the total transmission path. In networks that are
mously assume a preconfigured stand-alone mode even if
analysis of Ethernet networks places different require-
interest and over all protocol levels. >>To support heterogeneous networks, it must be possible
synchronized by the AVB protocol this dynamic delay may dis-
the measurement application is inactive. Otherwise, cer-
ments on the hardware and software. To avoid having to
to synchronize the interface with all commonly used bus
turb the time synchronization under certain circumstances.
tain Ethernet paths would be interrupted during the drive.
change interfaces for the different measurement setups, it
systems.
tool to analyze and manipulate data on all OSI layers of
must be possible to use the interface flexibly as a TAP, con-
For this measurement setup, it is possible to utilize tools and switches commonly used in the IT field. However, in the
TAP with Stimulation
verter or as a switch with supplemental functionality. The
The use of high-performance analysis tools from the field
BroadR-Reach networks that are generally used in the au-
Along with pure data analysis, the network must often be
of office communications together with external media
tomotive industry it is necessary to perform a media con-
tested by intentionally sending certain packets. Here – as in
following properties are desirable here: >>In the simplest case, when the interface is used as a TAP,
version to standard Ethernet (IEEE 802.3). Moreover, from
pure monitoring – the connections between any two nodes
the perspective of automotive network development these
should be affected as little as possible. However, these sup-
tools are usually insular solutions, and they have no reference
plemental packets cannot be sent on the physical layer, be-
to bus systems that are still important and commonly used.
cause an additional flow control is necessary, which is not
commonly used media such as BroadR-Reach, Fast
the VN5610 Ethernet/CAN interface from Vector together
available until layer 2. Here too, dynamic latency times oc-
Ethernet, Gigabit Ethernet and in the future RTPGE as
with the CANoe .Ethernet development tool. This solution is
Transparent Ethernet Analysis
cur, which could be compensated by protocol support di-
well. This eliminates the need to use external media
already being used by some automotive OEMs and suppliers.
Instead of using a classic switch as an interface, it is desir-
rectly at the interface, e.g. by AVB.
able to monitor the network by a method that is as trans-
One use is to send supplemental faulty data for test purposes
parent as possible. The primary objective here is to avoid
while the normal communication between the two nodes is
having the system affected by increased latency time or
running (path 3 in Figure 4). This data is either supplied di-
filtering of faulty packets. This can be done by a so-called
rectly by a test application, e.g. Vector CANoe .Ethernet, or
TAP (Test Access Point) (Figure 3), which acquires and
by a packet generator which generates a defined bus load
hardware level, because along with analysis the auto
tion, Ethernet will be used in other system domains and will
routes the data passively on the physical layer (path 1 in
directly at the interface (path 2 in Figure 4).
motive development process also requires controlled
to some extent replace other bus systems. After being used
stimulation. >>In conjunction with the simulation software the hard-
as a backbone, Ethernet and IP technologies will penetrate
Figure 4). In this process, the latency time is not only very short, but constant as well, which is especially advanta-
Remaining Bus Simulation
the TAP itself must only cause minimal and precisely specifiable latency times. >>The interface must be able to convert between all
converters, which has been necessary so far. >>For test drives, it must be possible to install the interface in the vehicle, and while it is not being used it must not disturb the network (stand-alone mode). >>Packet generators are important on the software or
converters is often overly simplified. The noted requirements can only be implemented by specialized hardware that is closely intermeshed with the analysis and simulation software. One combination already used in practice is
Outlook Over the next five to ten years, heterogeneous network structures will continue to be found as clusters of established bus systems in the vehicle. After the camera applica-
into other automotive application areas.
geous in the analysis of AVB systems. Another method of
Particularly when developing individual ECUs, the remain-
ware interface must allow real media access for one or
transparent monitoring involves using a switch with AVB
ing bus simulation [6] is a flexible way to test any types of
even several virtual network nodes (remaining bus
maining bus simulation and low-level time stamps for all data
time synchronization support. The AVB protocol then com-
scenarios before the ECUs are integrated in a real network.
simulation).
packets will continue to gain in importance. At Vector, the
pensates for the latency time that occurs when the packets
First, hardware is needed that permits unrestricted and high-
next development steps in the Ethernet and IP area will be
are routed.
performance network access. Second, the application must
to support users in signal representation over all IP protocol
Regardless of which method is chosen, to accurately ana-
be able to forward logged or self-generated data to the
layers (Figure 1) and to comprehensively check real-time and
lyze the packet data precise time stamps are needed which
hardware (path 4 in Figure 4). And third, the combination
service-oriented communication, e.g. via AVB and SOME/IP.
are acquired as close to the physical layer as possible. These
of hardware and software must be able to receive packets,
time stamps must be synchronized with other interfaces,
corrupt them and then send the corrupted packets. This
Translation of a German publication in Hanser automotive,
because the network analysis often focuses on more than
provides a way to test ECU behavior in response to specific
April/2013
just one Ethernet path (Figure 2).
error cases such as protocol errors.
For developers of vehicle networks, multibus capability, re-
Image rights: Vector Informatik GmbH Literature References: [1] OPEN Alliance SIG, http://www.opensig.org/ [2] Das IP-basierte Bordnetz kommt [“The IP-based onboard electrical system is coming”], Elmar Frickenstein, BMW AG, SEIS Status seminar, 2011-20-09, http://www. strategiekreis-elektromobilitaet.de [3] Ethernet und IP im Kraftfahrzeug: Neue Anforderungen an das Entwicklungswerkzeug durch den Ethernet- und IP-Einsatz [“Ethernet and IP in motor vehicles: New development tool requirements for the use of Ethernet and IP”], Figure 3: Possible wiring of Ethernet interfaces for analysis or for a remaining bus simulation. Synchronism with familiar automotive bus systems is also required.
1/50
Figure 4: The VN5610 Ethernet/CAN interface passively and actively participates in communication in Ethernet networks together with CANoe .Ethernet/CANalyzer .Ethernet. A flexible configuration supports different measurement setups for analysis and test purposes.
Hans-Werner.Schaal, Elektronik automotive, April 2012 [4] Herausforderungen von Ethernet-Debugging [“Challenges of Ethernet debugging”], Helge Zinner, www.elektroniknet.de, October 2012
1/51
[5] ISO CD 17215-1 (E) of 2012-07-02 [6] Schnelle Wege zur Restbussimulation: Virtuelle Netz werke ohne Programmier-Know-how erstellen [“Quick paths to remaining bus simulation: Creating virtual networks without requiring programming know-how”], Stefan Albrecht and Peter Decker, Automobil Elektronik, March 2012 Links: Vector: www.vector.com Vector Solutions for IP and Ethernet: www.vector.com/vi_automotive_ethernet_solutions_en.html Hans-Werner Schaal (Dipl.-Ing.) is Business Development Manager for the area of IP, Car2x and open CAN protocols such as J1939 and ISO11783 at Vector.
Matthias Schwedt (Dipl.-Ing. (FH)) is FPGA developer for Ethernet, FlexRay and MOST150 network interfaces as well as overall project leader for the VN56xx Ethernet network interface family at Vector.
1/52
Figure 1: Excerpt from a heterogeneous network architecture with Ethernet networks.
New Perspectives on Remaining Bus Simulation for Networks with SOME/IP Validating Automotive IP Network Elements Ethernet based on BroadR-Reach is already a reality in vehicles with camera applications, and it will reach other application areas as well. Specialized development tools even permit time-synchronous display of the communication of heterogeneous networks. To enable bandwidth efficiency, automotive IP networks – in contrast to static CAN communication – are set up in a dynamic and service-oriented way. Therefore, the development tools must also support service-oriented protocols such as SOME/IP.
1/54
possible to set up notifications for specific events (Figure 3,
wards all received packets to the monitor port. One disad-
Part B). The application can use read and write functions to
vantage of this solution is that the received data packets
access any specific process data (Figure 3, Part C). The
do not have any common time reference – there are no
goal of SOME/IP is to optimally utilize available bandwidth
time stamps. For another, it is often the case that only valid
to implement very flexible communication. The communi-
packets are forwarded to the monitor port, which makes
cation and the signals are described using FIBEX 4.1 or
error analysis difficult.
higher or AUTOSAR formats version 4.1 or higher.
Media access with little effect on the network under analy-
For the remaining bus simulation, SOME/IP serves as a
sis is provided by a so-called TAP (Test Access Point) [2].
complex protocol and middleware with all of its degrees of
Unlike a standard switch, this TAP makes it possible to
freedom. To keep user complexity as low as possible, the
transparently analyze an Ethernet network without affect-
remaining bus simulation is largely configured autonomous-
ing the communication between two nodes (Figure 4, flexi-
ly. This involves the use of standardized description formats
ble TAP). The TAP may be operated in two different modes,
such as FIBEX 4.1 or AUTOSAR. This gives users direct access to the signals. However, manual overwriting of the
depending on the following requirements: >>The purely passive operating mode guarantees short and
configuration is desirable in executing tests, e.g. to provoke
constant latency time, but in this mode it is only possible
error cases.
to listen on the medium.
Flexible Network Access for the Test Tool
Taking the example of SOME/IP (Scalable Service-Oriented
the protocols used must be incorporated into existing
Middleware on Ethernet / IP), this article shows how to
systems. In particular, this relates to good integration in
Implementing the complex task of a test tool – such as a
implement a remaining bus simulation [1] for dynamic,
AUTOSAR and fast reaction times to keep delays short in
remaining bus simulation – as optimally as possible requires
service-oriented IP networks (Figure 1). Afterwards, the
case of error. BMW AG has developed and specified SOME/
that the application has flexible and high-performance ac-
aspects of media access, synchronization and controlled
IP, which is an open protocol that fulfills automotive re-
cess on the physical medium (Figure 4, remaining bus simu-
stimulation [2] are discussed, and recommendations for
quirements. A SOME/IP implementation is available from
lation). Using this access, the developer must be able to
the development system are derived from them.
Vector for use in ECUs, including a TCP/IP stack, Service
generate error cases (e.g. CRC errors) on the network. If
Discovery and BroadR-Reach Ethernet driver.
the primary focus is on analyzing a connection between two
Use of Service Protocols Based on the Example of
SOME/IP offers interfaces for service-oriented communi-
nodes, special measures must be taken to enable transpar-
SOME/IP
cation (Figure 2). This distinguishes it from the pure signal-
ent, interference-free access. This is necessary, because al-
In the Ethernet and IP field, there are a tremendous num-
based communication that is usual in CAN, for example.
though Open Alliance BroadR-Reach (OABR) is logically a
ber of protocols to choose from, and one might think that
SOME/IP is roughly subdivided into three areas: Service
bus system, electrically it is a point-to-point connection.
protocols already exist that could be used directly in all con-
Discovery (SD), Remote Procedure Call (RPC) and access
An obvious solution is to use an additional monitor port on
ceivable types of applications. However, since networking
to process data. The SD area lets ECUs find services or of-
the switches used in the system. However, for cost reasons
in the vehicle does not start at zero, certain specific re-
fer their services in the network. The user utilizes methods
this cannot always be done in the production version sys-
quirements become immediately apparent. For example,
offered by SD via RPC (Figure 3, Part A). In addition, it is
tem [3]. Using what is known as mirroring, the switch for-
Figure 2: SOME/IP offers an interface for calibration.
1/55
New Perspectives on Remaining Bus Simulation for Networks with SOME/IP
>>Does the development system support service-oriented
[2] Neue Werkzeuge für Automotive Ethernet (“New tools
communication like SOME/IP? >>Does the development system provide logging and
for automotive Ethernet”), Hans-Werner Schaal, Matthias
controlled stimulation with and without protocol violation? >>Does the development system offer access to typical
Schwedt, Hanser automotive 3-4/2013 [3] Herausforderungen von Ethernet-Debugging (“Challenges of Ethernet debugging”), Helge Zinner, www.elektroniknet.de, October 2012
automotive networks such as OABR, CAN, FlexRay and MOST? >>Can the interface be used flexibly as a TAP for mirroring and as a converter and switch [2]? >>Can the interface for supporting heterogeneous
Hans-Werner Schaal (Graduate Engineer) is Business Development Manager in the areas of Automotive Ethernet, Car2x and open CAN protocols such as J1939 and ISO11783 at Vector Informatik GmbH.
networks be synchronized with all commonly used bus systems and IP networks? The development tool CANoe .Ethernet supports all of these functions with the VN5610 Ethernet/CAN interface from
Matthias Schwedt (Dipl.-Ing. (FH)) is FPGA developer for Ethernet, FlexRay and MOST150 network interfaces as well as overall Project Leader for the VN56xx Ethernet network interface product line at Vector Informatik GmbH.
Vector. Therefore, it is already being used at some auto motive OEMs and suppliers. Figure 3: SOME/IP offers various types of access such as RPC, notifications and read and write functions.
Outlook IP-based, service-oriented communication is making great
Peter Fellmeth (Dipl.-Ing. (FH)) is Group Leader and Product Manager at Vector Informatik GmbH. He is responsible for developing products and customer- specific projects in the Ethernet, J1939 and ISOBUS fields.
strides forward. After being used in camera applications, Ethernet will be used in the infotainment area and then in >>In the active mode, additional data may be injected into an existing connection.
other system domains, e.g. as a backbone. For developers of vehicle networks, the significance of multi-bus capability, remaining bus simulation and low-level time stamps for
The active connection cannot be made on the Physical Layer
all data packets continues to grow.
(OSI Layer 1), however, because additional flow control is necessary. Flow control is not available until Layer 2. None-
Translation of a German publication in Automobil Elektronik,
theless, flow control cannot guarantee constant latency time.
4/2013
Regardless of the method chosen, precise time stamps obtained as close as possible to the Physical Layer are nec-
Image rights:
essary for precise analysis of the packet data. These time
Vector Informatik GmbH
stamps must be synchronized with other interfaces, because network analysis often focuses on more than just one Ether-
References:
net path as well as on other automobile networks.
[1] Schnelle Wege zur Restbussimulation: Virtuelle Netz werke ohne Programmier-Know-how erstellen (“Quick
Choosing the Development Tool
paths to the remaining bus simulation: Creating virtual
Based on the above considerations, every developer should
networks without programming know-how”), Stefan Al-
ask five questions before choosing a development tool:
brecht and Peter Decker, Automobil Elektronik 03/2012
Figure 4: The VN5610 interface is used in various application cases.
1/56
1/57
without increased costs for wiring. It also offers the bene-
and FlexRay implement the AUTOSAR Protocol Data Unit
fits of a switched network, which enables implementation
(PDU) interface directly, the Ethernet Interface routes raw
of a backbone architecture, for example (Figure 1). Other
data to the TCP/IP stack or receives data from it. The IP,
applications that are currently of interest to automotive
UDP and TCP protocols are processed in the TCP/IP stack,
OEMs and their suppliers include Audio Video Bridging
which however is not fully specified in AUTOSAR 4.0. The
(AVB), network management and new gateway ECU con-
use of a common off-the-shelf TCP/IP stack is recommend-
cepts.
ed here.
Ethernet in combination with the Internet Protocol (IP),
A paradigm upon which the TCP/IP protocol family is based
Transmission Control Protocol (TCP) and User Datagram
is the use of sockets. A socket is uniquely identified by the
Protocol (UDP) also enable the transition from a data-ori-
combination of IP address and port of the remote and local
ented to a service-oriented communication schema. BMW
end nodes. Via a socket, packet-oriented UDP and connec-
has developed a serialization protocol, the Service Oriented
tion-oriented TCP user data are routed from the TCP/IP
Middleware over Internet Protocol (SOME/IP), which
stack to the application or in the opposite direction. This
among other things can be used for remote procedure calls.
paradigm is incompatible with the PDU concept of AUTOSAR.
It is complemented by the Service Discovery (SD) protocol
Transformation of socket-based communication into PDU-
that was also specified. ECUs use Service Discovery to in-
based communication and in reverse is the task of the
form communication partners of the availability of their
Socket Adaptor Module (SoAd). It provides the familiar
services. ECUs can also use it to search for services and
PDU interface to higher level modules, which fully inte-
register their events.
grates the Ethernet stack in the AUTOSAR architecture. The Ethernet stack specified in AUTOSAR 4.0 has estab-
AUTOSAR Learns Ethernet Ethernet is a new and yet old and familiar network technology that is making its way into vehicles. At first, it is just being used for diagnostic applications and intelligent charging of electric vehicles, but onboard Ethernet networks are now being implemented as well. This article describes the properties and advantages of Ethernet and discusses the special aspects of integrating the technology in AUTOSAR. Finally, useful extensions are presented for an AUTOSAR Ethernet Stack which can be used to implement new applications.
1/58
Until just a few years ago, CAN and LIN were the only bus
easy to integrate a DoIP-based diagnostic tester in an ex-
systems being used in vehicles. The desire for more band-
isting service-garage network. DoIP laid the foundation for
width and growing requirements in the safety field, espe-
the use of Ethernet in vehicles. When electric mobility be-
cially with regard to X-by-wire systems, led to the develop-
came a central topic a short time later, the focus shifted
ment and introduction of FlexRay. The MOST standard also
towards Ethernet-based Vehicle-to-Grid applications. In
became established for high-end applications in the multi-
the charging process, the electric or hybrid vehicle commu-
media field. Unlike CAN, FlexRay and MOST are complex
nicates with an energy provider’s charging spot. The com-
and expensive bus systems. Because of this, and due to the
munication is based on TCP/IPv6 and a dedicated Smart
lack of a service-garage network for these bus systems,
Charge Communication (SCC) protocol, in order to exchange
CAN was still used for external access in vehicle diagnos-
such information as the charging type (AC/DC), date and
tics. However, the time required to program ECUs increased
time of charging, duration of charging and rate and pay-
dramatically due to the limited bandwidth of CAN and the
ment information.
increasing amount of software content. The Diagnostics
The standard shielded Ethernet cable with its high wiring costs
over Internet Protocol (DoIP) was developed several years
prevented widespread use of the technology for in-vehicle
ago to resolve this problem. This protocol is the first to be
networks. However, introduction of the new BroadR-Reach
based on Ethernet as the network technology in the vehicle
physical layer has made the option of Ethernet interesting
environment, and it is standardized in ISO 13400. Ethernet
for in-vehicle communications as well. Using twisted pair
offers the advantage of high bandwidth, and it has primar-
lines, BroadR-Reach offers a bandwidth of 100 MBit/s which
ily taken hold in the office and Internet worlds. It makes it
represents a 100-fold increase in speed compared to CAN
Ethernet and AUTOSAR
lished a foundation for receiving and sending PDUs over
Ethernet has been part of the AUTOSAR standard since
Ethernet. It also considers the use case DoIP. The imple-
Version 4.0. In the AUTOSAR architecture, the Ethernet
mentation of the DoIP protocol shall be realized as Socket
communications stack is laid out in parallel to the CAN, LIN
Adaptor plug-in. Moreover, this AUTOSAR version supports
and FlexRay stacks. However, unlike them, it exhibits a
ECU calibration via XCP over Ethernet and network man-
number of special aspects – which relate to the higher pro-
agement over UDP, and it offers an interface for connect-
tocol layers IP, UDP and TCP in particular. The Ethernet
ing AUTOSAR Complex Drivers (Cdd). Automated data
Transceiver Driver (EthTrcv) and Ethernet Driver (Eth)
parameterization of the Ethernet stack is only partially
modules are comparable to those of other network tech-
covered in AUTOSAR 4.0. The user can represent Ethernet
nologies. The Ethernet Interface (EthIf) module, on the
networks, frames and PDUs in the AUTOSAR System
other hand, is different. While the interfaces for CAN, LIN
Description or in the ECU Extract of System Description.
Figure 1: Potential domain architecture for future motor vehicles with Ethernet networks.
1/59
AUTOSAR Learns Ethernet
>>The TCP/IP stack is now an AUTOSAR module.
Useful Supplements from Practice
Links:
>>Besides version 4 of the Internet Protocol, version 6 is
As already mentioned, some applications of the Ethernet
Vector: www.vector.com
also supported. The two IP versions can be operated
stack, such as Smart Charge Communication, are not
MICROSAR basic software: www.vector.com/microsar
either individually or in parallel in one ECU. >>It is now possible to use Virtual Local Area Networks
covered by AUTOSAR specifications. For this purpose, there
(VLANs). >>PDU-based data transmission over the Socket Adaptor
Producers and suppliers of electric and hybrid vehicles need
is much more efficient. >>In its new version, the Socket Adaptor offers a generic
charging. Ideally, the protocols would be seamlessly inte-
interface to higher level modules. >>Implementation of the DoIP protocol was removed from
Per specification, the Universal Measurement and Calibra-
the Socket Adaptor and relocated to a separate DoIP
Ethernet is used for vehicle access, it is also nessesary to
module. >>The Service Discovery protocol is also specified as a new
calibrate all ECUs that are not directly connected to the
AUTOSAR module.
are ISO and DIN standards, which Vector helped to create. the protocols specified in these standards for intelligent
Marc Weber (M.Eng.) is responsible for product management of the Ethernet stack in the Embedded Software product line.
[email protected]
grated in an AUTOSAR Ethernet stack. tion Protocol (XCP) does not have routing capability. When
Ethernet network over XCP. Vector developed a mechanism that enables this in cooperation with a German automotive OEM.
The SOME/IP protocol and the use cases SCC and AVB are
Routing of DoIP over a gateway to a sub-Ethernet network
still not covered in AUTOSAR. The description of a sample
is not standardized in the ISO 13400 specification. None-
implementation of SOME/IP is available as a supplemental
theless, solution approaches have already been worked out
document to the current standard.
with various automotive OEMs.
In practice, only FIBEX 4.1 has been used so far as the de-
The Ethernet stack defined in AUTOSAR is available from
Pre-filling of data for higher protocol layers, e.g. definitions
scription format for in-vehicle Ethernet networks. It has
Vector as ECU software under the product name MICROSAR
of IP addresses and ports, is not specified.
now been harmonized with AUTOSAR 4.1.1. This means that
IP (Figure 3). It contains the functionality specified in
although the two description formats are not identical,
AUTOSAR 4.0.3 and 4.1.1 and is also available for AUTOSAR
Extended Ethernet Support in AUTOSAR 4.1
their contents can be transformed from one format to the
3.x projects. The extensions mentioned above are included,
With the introduction of in-vehicle Ethernet networks, new
other without loss of information. To a large extent, this
as well as a resource-minimizing implementation of SOME/
requirements have evolved, which an AUTOSAR 4.0 Ether-
enables automated data parameterization of the Ethernet
IP. The architecture of MICROSAR IP permits implementa-
net stack does not fulfill. It is very difficult to implement
stack per AUTOSAR 4.1.1 (Figure 2).
tion of customer-specific extensions without any problems.
Figure 2: An Ethernet stack is configured with an AUTOSAR 4.1 description file.
efficient transmission of multiple PDUs, for example. Therefore, the Ethernet stack was revised significantly in
Outlook
AUTOSAR 4.1.1:
One feature of AVB is that it enables time-synchronous transmission of audio and video streams over Ethernet. The IEEE 1722 transport protocol that is needed for this is already available from Vector. AVB support is currently being extended, e.g. by integrating time synchronization with the Generalized Precision Time Protocol. In AUTOSAR version 4.2.1, there will presumably be some extensions related to the Ethernet stack. Current efforts include adopting data serialization via SOME/IP into the standard. These plans also include supporting data serialization for sender-receiver communication. Currently, this is only possible for client-server connections. Another document describes the introduction of a second communication module, which is specially designed for efficient sending and receiving of serialized data. Other concepts currently under discussion relate to the allocation of IP addresses and global time synchronization across different networks. Translation of a German publication in Hanser automotive, October 2013
Figure 3: The AUTOSAR Ethernet stack MICROSAR IP from Vector contains AUTOSAR modules and useful supplements.
1/60
Image rights: Vector Informatik GmbH
1/61
Figure 1: A database contains both system and data descriptions
With CAN FD, the previously mentioned complexity of de-
>>Use of all 64 payload data bytes for efficient bus
fining the communication matrix is significantly increased once again. To ensure efficient communication in this case,
utilization. >>The previously defined PDUs must not be changed.
network designers must logically group signals in messages
>>The gateway must not become significantly more
that are up to 8 times larger. Some scenarios also require
complex.
that PDUs defined previously for CAN are available on CAN
New Communication Paradigms in Automotive Networking
All of these requirements can be met by the sending of mul-
greater payload data length. Assistance is provided by the
tiple previously-defined CAN PDUs in one CAN FD message
n-PDU-to-frame mapping, which allows the sending of
by the gateway.
multiple PDUs in one message.
Up to now, the content of a message was identified by the respective CAN identifier (CAN ID). The receiver can no lon-
Exemplary n-PDU-to-frame Mapping in a Gateway
ger use the CAN ID for data identification since a CAN FD
Scenario
message contains multiple PDUs. A possible solution would
In a gateway scenario (Figure 2), the bandwidth of a classic
be to define the content of the CAN FD message statically
CAN bus may no longer be sufficient. Let’s assume that
in a database. In contrast, with n-PDU-to-frame mapping,
three CAN buses are connected to a gateway and all are
the database defines the PDUs that can potentially be con-
already being operated at the bus load limit. An ECU that
tained in the CAN FD message. The PDUs that the ECU
requires much of the data of the other two buses is at-
actually sends are chosen during runtime. The described
tached to CAN bus 3. The gateway is responsible for rout-
scenario is presented schematically in Figure 2. Each ECU
ing the needed data to the ECU. If, due to a change of gen-
on CAN bus 1 and CAN bus 2 as well as the gateway itself
eration, the ECU on CAN bus 3 has a need for additional
sends a PDU that is to be transmitted on the CAN FD bus.
communication, the bandwidth of CAN bus 3 is no longer
The gateway fills up the CAN FD message step-by-step
CAN FD, the Improved CAN Bus
sufficient. CAN FD should therefore be used instead. In ad-
with the PDUs up to the time of sending. A small header is
data bytes. For reasons of efficiency, it is advantageous to
The maximum transmission rate of 1 Mbps on the CAN bus
dition, there are further requirements:
put in front of each PDU so that a receiver can extract the
use all eight bytes to maintain the best possible ratio be-
is no longer sufficient for all of today’s communication
tween payload data and protocol overhead. However, the
demands. A solution to the bandwidth problem is to use
individual data elements (signals) being transmitted, such
CAN with flexible data rate (CAN FD). This enhanced ver-
as wheel speed, are often less than eight bytes in length.
sion of the CAN protocol features transmission rates of up
Several signals are therefore sent together. Each bit is valu-
to 8 Mbps. This is achieved by two enhancements to classic
able, and thus the task of defining each CAN message with
CAN: >>1. The payload data bytes are transmitted at a higher bit
Ethernet and CAN FD are the New Trailblazers CAN is the prevailing bus system for communication between electronic control units (ECUs) in today’s vehicles. The communication demand has increased dramatically in recent years, and vehicle manufacturers are now reaching the limits of vehicle networking with CAN. Ethernet and CAN FD provide higher bandwidth and are taking over some of the tasks of existing bus systems. The higher bandwidth is one aspect, but also of high relevance is the introduction of new communication paradigms.
A classic CAN message transmits a payload of up to eight
the signals contained therein becomes very complex. The communication matrix is defined in a database. For
rate. In order for the other properties of CAN, such as
CAN this is done in one of the following formats: DBC,
the maximum cable length, to remain the same as
FIBEX, or AUTOSAR System Description. The database
possible, the header and trailer of a CAN message are
(Figure 1) contains not only the messages and their compo-
sent at the normal bit rate. >>2. A CAN FD message contains up to 64 payload data
sition but also the associated send and receive relation-
1/62
FD as well. This would eliminate the advantage of the
ships. Also defined in the database are the Protocol Data
bytes. If an eight times faster bit rate is used and 64 pay
Units (PDU) – an abstraction layer between signals and
load data bytes are sent, the transmission time is compar
messages.
able to a classic CAN message with 8 payload data bytes.
Figure 2: Possible scenario for introduction of CAN FD
1/63
New Communication Paradigms in Automotive Networking
individual PDUs from the message. The gateway no longer
ing CAN or FlexRay PDUs 1:1 on Ethernet. The sending of
Every Ethernet node has a MAC address, which is used for
cast) and 1:all (broadcast) communication as well. If these
has to pay attention to the order of the PDUs and is spared
multiple PDUs within one message, which was described
unique addressing in the network. A node processes a mes-
addressing methods are not used skillfully, the described
the complex task of keeping the defined message layout.
for CAN FD, can be used for Ethernet unchanged. In con-
sage when its MAC address is specified as the destination.
advantages of Ethernet are lost.
This keeps the demand for resources on the gateway as low
trast to CAN FD and FlexRay, AUTOSAR specifies two
In other words, the sender must know the receiver and en-
In the case of unicast addressing, the intelligence migrates
as possible.
equivalent approaches for Ethernet. The first approach is
ter the corresponding destination address in the message.
on the network from the receiver to the sender. The sender
the n-PDU-to-frame mapping in the I-PDU Multiplexer,
This 1:1 communication relationship uses so-called unicast
must know which receivers in the network are interested in
The sending of a CAN FD message is triggered by various
which has already been described for CAN FD. The same
addressing. If a unicast-addressed message is sent to all
which data (PDUs) and must assemble the messages ap-
events, such as: >>1. The send buffer of the message is full.
PDU collection algorithm is specified in the Socket Adaptor
network nodes, only one receiver processes the packet. All
propriately using n-PDU-to-frame mapping. It is possible
module, which is responsible for linking the TCP/IP stack to
other receivers discard it. To prevent flooding the network
for PDUs or messages to be sent multiple times if there are
>>2. The timeout defined for the complete message
the rest of the AUTOSAR architecture. The user can use
unnecessarily, the switch as an active network connection
multiple receivers for the same PDUs. This receiver-specific
expires. >>3. After expiration of the timeout defined for a single
both approaches. When the Socket Adaptor is used, addi-
element was introduced. After a brief learning phase, a
data fan-out can be implemented most easily in AUTOSAR
tional control possibilities for Ethernet-based communica-
switch forwards messages only to the connection where
with the Socket Adaptor.
PDU, the message containing this PDU is sent. >>4. A PDU has an additional attribute that triggers imme-
tion are available.
the addressed destination can be reached. The available bandwidth is thus used efficiently. Furthermore, a switch
New Communication Paradigm: Service-oriented
diate sending of the message after the PDU is copied to
Different Network Topology with Ethernet
enables multiple unicast-addressed messages to be sent
Communication
the send buffer.
Besides the payload data length, Ethernet differs signifi-
simultaneously on the network. Figure 3 shows an example
The properties of Ethernet as well as the desire of vehicle
cantly from other network technologies in regard to net-
Ethernet network with two switches: One in the ECU at the
manufacturers for more flexibility and controllability of the
The option of sending multiple PDUs in one message has
work topology and addressing (Figure 3). CAN uses a clas-
top of the figure, the second in the unlabeled ECU. High-
networking complexity led to the introduction of service-
been defined in AUTOSAR since release 4.2.1. The mecha-
sical bus topology while FlexRay can be physically imple-
lighted in color are parallel, non-interfering communication
oriented communication in the automotive environment.
nism is specified independent of the network technology in
mented with a star topology, from a logical standpoint it
paths through the network. All connections support up to
This familiar communication paradigm from the Internet
the I-PDU Multiplexer module so that it can be used, for
behaves like a bus, too. In the case of both network technol-
100 Mbps full-duplex data transmission. As a result, the
world has been transferred to vehicle networking. However,
example, for FlexRay or Ethernet in addition to CAN FD.
ogies, a message is sent to all nodes. Each network node
bandwidth of 100 Mbps is multiplied by the number of par-
specific protocols optimized for automotive applications are
Besides the pure collection of PDUs, the module also sup-
decides independently whether a message is relevant to it
allel communication paths. Ethernet provides 1:n (multi-
being used: Service Discovery (SD) and Scalable Service-
ports the different sending conditions and two different
and will be further processed. This is done using the CAN ID
oriented Middleware over Internet Protocol (SOME/IP). Up
PDU header formats. For CAN FD and FlexRay, a 4-byte
for CAN and the Slot ID for FlexRay. In either case, the ID
to now, we spoke of senders and receivers in the vehicle
header is primarily used while an 8-byte header is generally
already classifies the content of the message. There is no
network. With service-oriented communication there is one
used on Ethernet.
option of selectively sending a message to only one receiver.
ECU that provides a service (the server) and ECUs that use
For this reason, CAN and FlexRay are broadcast media. At
this service (the clients).
Ethernet Provides a Much Larger Payload Data Length
the beginning of its success story, Ethernet was also a bus
Servers use the Service Discovery protocol to announce
Compared to CAN, Ethernet provides a maximum payload
system. The cabling was implemented with coaxial cables
which services they provide at runtime and how these ser-
data length that is more than 185 times larger. A classic
and T-elements. Today, Ethernet is, in the vast majority of
vices are addressed. Clients invoke methods of the server
definition of hundreds or even thousands of signals within
cases, an actively switched network with tree topology in
(Remote Procedure Calls) or subscribe at the server, in
a 1500-byte PDU is not really feasible. For gateway appli-
which collisions cannot occur due to point-to-point connec-
order to subsequently receive data updates automatically.
cations, however, it can be advantageous to forward exist-
tions.
In the latter case, the server provides certain data elements (called events) and sends their values to all subscribed clients. The application of the server triggers the sending of data updates. The n-PDU-to-frame mapping enables multiple events to be sent within one message. Figure 4 graphically represents the two principles of service-oriented communication. For method invocations and data updates, the length of the data to be transmitted can vary significantly. The support for this variable data length is a main feature of SOME/IP. It serializes structured and complex application data so that the remaining basic software of an ECU only has to take care of sending or receiving a byte stream. For this reason, the exact message layout is no longer defined in a database. AUTOSAR fully supports SD and SOME/IP. Because of the platform independence of SD and SOME/IP, the protocols
Figure 3: Comparison between network topologies of CAN (FD), FlexRay and Ethernet
1/64
Figure 4: Operating principles of service-oriented communication using Service Discovery
are also used for data exchange between AUTOSAR ECUs and other platforms.
1/65
Conclusion With their greater payload data length, CAN FD and Ether net provide new data transmission possibilities. They also create new challenges for vehicle manufacturers and their suppliers – for example, when creating the system description. Assistance is provided by n-PDU-to-frame mapping, which packs multiple PDUs in one CAN FD or Ethernet message. In the case of Ethernet, however, there is not only an increase in the user data length but also in available bandwidth. Furthermore the switched network and associated new addressing method represent a small revolution in the automotive environment. New mechanisms for data distribution are necessary. Building on this, data exchange is becoming more dynamic by means of service-oriented communication. AUTOSAR 4.2.1 already supports all of the presented mechanisms and thus facilitates implementation of the new communication paradigms. Basic software implementations of this AUTOSAR version are already available on the market. An example is MICROSAR from Vector along with the development tool CANoe which offers convenient analysis and testing of CAN FD and Ethernet networks. A shortened version of this article was published in the German magazine Automobil Elektronik, issue 7/8 2015. Image rights: Vector Informatik GmbH Links: Website Vector: vector.com Product information MICROSAR: www.vector.com/microsar Product information CANoe: www.vector.com/canoe M.Eng. Marc Weber is responsible for product management of the Ethernet stack for the Embedded Software product line of Vector Informatik.
1/66
Technical Article / April 2016
topology of bus systems such as CAN, LIN and FlexRay.
As mentioned, a switched Ethernet network consists of
There are no bus conductors to which numerous ECUs, sen-
many 1-to-1 connections (Figure 1) whose full-duplex trans-
sors and actuators are jointly connected. Instead, it is a
mission makes access without effect on the network nearly
network of switches and many electrical point-to-point
impossible. Even tapping the data signal at the network
connections. In such fully switched networks, the topology
cable between two switches or ECUs with an ideal, high-
– i.e. the layout of individual nodes – plays an important
impedance measurement system to passively listen to
role, especially when it comes to real-time capability. Tech-
data traffic is of little use, because the tapped signals can-
nologies such as AVB (Audio Video Bridging) and TSN (Time
not be decoded. Only the counterpart ECU at the other end
Sensitive Networking) have implications for switches and
of the transmission line can decode the received informa-
ECUs, and in the future they will enrich Automotive Ether-
tion by differentially comparing it with its own signal from
net networks with functions such as prioritization of data
the signal mix.
packets and time synchronism. In practice, there is no alternative to splitting a 1-to-1 conAll of this noticeably increases complexity and has effects
nection of interest and inserting additional hardware such
on development, testing and simulation of the related net-
as a TAP (Test Access Point) (Figure 2). A TAP provides two
works. Convenient network access by test and simulation
Ethernet ports and a connection to the computer with the
tools has always been an important aspect of the develop-
analysis tools that can distinguish the different operating
ment process, and Automotive Ethernet is no exception.
modes of a TAP. For pure monitoring, passive TAPs are suf-
However, switched networks lack “the one bus” on which all
ficient, which loop through the data on ISO-OSI Layer 1, i.e.
signals and messages can be accessed or test messages
the physical level. In this process, the TAP is essentially
can be sent out. This leads to the question: What capabili-
transparent with regard to key communication properties.
ties and properties does an interface hardware device need
Errors in transmitting Ethernet packets are passed and not
to offer to meet current and future requirements?
rejected. To achieve time synchronization in the network, it is important to keep the unavoidable pass-through delay
Measurement With no Effect on The Network is Practi-
constant and minimal. However, as soon as one wishes to
cally Impossible
intervene in events and modify data, active TAPs are need-
The basic requirements of an interface for Automotive
ed. Comparable to a switch, they operate on the Data Link
Ethernet do not really differ from those for other commu-
Layer (Layer 2).
nication systems: with a rugged housing, reliable plug con-
Full Transparency with Automotive Ethernet Finally seeing what is really happening Automotive Ethernet – in contrast to CAN, LIN and FlexRay – is not simply another bus that sparkles with very high transmission rates. Rather development and testing departments are confronted with an entirely different network topology, which in many aspects requires a different approach to thinking and acting. This article describes, based on the example of a new flexible Automotive Ethernet interface, the specific challenges that developers face. It also demon-
nectors designed for many plug-in cycles and an extended
Functional Development vs. Network View
temperature range, the hardware is equally well-suited for
In pure functional development, a TAP is often sufficient,
the laboratory and for outdoor in-vehicle applications. The
because here the focus is generally on an individual connec-
software tools require extensive network access, which
tion between two network nodes, e.g. from ECU-to-ECU or
means that the interface needs to be able to handle both
ECU-to-switch. Along with purely passive listening to indi-
passive read accesses and active write accesses. Important
vidual connections, the software tools also perform tasks
for all of these activities, of course, are highly precise time
such as the remaining bus simulation and inserting addi-
stamps and the ability to synchronize with other interfaces
tional data packets and disturbances. The situation
and other bus systems in multibus environments. The hard-
strates the ideal way to structure hardware and software and have them interact to achieve optimal development, sim-
ware communicates with the simulation or analysis tools
ulation and test results under the new constraints.
via a stable and high-performance host interface.
The central appeal of Ethernet in the automotive industry
Open Alliance BroadR-Reach), high-speed networks can be
is that it offers tremendous gains in bandwidth, which is
implemented easily and cost-effectively based on a single,
playing an increasingly more important role in current and
unshielded twisted pair cable (UTP). The system is capable
future applications. Systems for autonomous driving and
of transmitting a gross data rate of 100 MBit/s simultane-
Advanced Driver Assistance Systems (ADAS) are always in
ously in each direction. Based on the full-duplex method, it
need of most current data about the surroundings from
can therefore achieve an overall rate of 200 Mbit/s.
cameras and radar systems. There, and in other areas, high
1/68
transmission rates are needed, e.g. to quickly transmit
Network of 1-to-1 Connections and Switches Instead of Bus
video streams and sensor data. But the time and cost
System
advantages of a high bandwidth are even welcome in such
However, this large bandwidth advantage comes at the
tasks as flashing large numbers of ECUs. Using the IEEE
cost of a paradigm shift for the automotive industry,
standard for Automotive Ethernet, 100BASE-T1 (OABR,
because Automotive Ethernet differs significantly from the
Figure 1: Example of a switched Ethernet network that consists of multiple 1-to-1 connections.
01
Figure 2: A typical measurement setup in which signals are accessed by splitting the 1-to-1 connections and looping them through interfaces. A common time base must be provided for precise analysis.
1/69 02
Technical ArticleEthernet / April 2016 Full Transparency with Automotive
Technical Article / April 2016
neously, they have to insert their interfaces at multiple
necessary to specially modify the ECU just to be able to
just the number of ports that is crucial here, as has already
points. If the latter are discrete devices, a synchronization
perform testing – which is a highly inefficient working
been shown above. It is important to understand that – up
mechanism is needed now at the latest, so that all inter-
method.
to now – simply shifting a device between simulation and
faces are operating to the same time base and the tests
the real world was equivalent to a change in topology. If Shifting Complexity to Software and Hardware Tools
users are only equipped with conventional standard com-
This situation can be remedied by a specialized tool that
ponents and tools, such seemingly simple work steps can
In addition to network access, the topology also represents
makes it possible to place a special TCP/IP stack instance
pose enormous challenges. Given this situation, what are
a challenge in switched networks. An example from prac-
after each simulated ECU (Figure 4). Together with the
the key properties of a powerful Automotive Ethernet
tice illustrates the fundamental problem in testing an indi-
interface hardware, the user can then stimulate the real
interface that is suitable for the future? Ideally, an inter-
vidual ECU: The real device under test is connected, via an
ECU so that the simulated communication matches the
face decouples the simulation from the direct Ethernet
Automotive Ethernet interface, to the test computer on
real communication. Over further course of testing, a col-
ports by inserting what is known as an application channel
which two virtual ECUs run for the remaining bus simula-
league might erroneously come up with the idea – one that
between them on the PC side. Moreover, it fills the gap
tion. Usually the PC with the simulation tools has exactly
is familiar from CAN – of “just removing” one of the simu-
between the application channel and the 100BASE-T1
becomes difficult when analyzing Automotive Ethernet
one TCP/IP stack, so that the two virtual ECUs can com-
lated ECUs from the simulation and replacing it by its real
ports with a user-configurable transfer function (Figure 4).
scenarios that are more complex, in which developers need
municate externally to the interface via the common stack.
counterpart. When the user connect it to an available Eth-
A typical and frequently needed transfer function is the
an overview of the entire system (Figure 3). Then the
The data traffic generated by the PC does not by any
ernet port on the interface, would it work? Unfortunately,
switch functionality.
attention is on entire data paths. In addition to total trans-
means represent a real situation. That is because the ECU
this approach ignores the fact that Ethernet networks only
mission times and pass-through times in the switches,
under test cannot distinguish the messages of the two
permit 1-to-1 connections. A 1-to-1 connection exists in the
The use of an FPGA makes it easy to implement further
users are interested in detailed information about rejected
simulated ECUs, since they act under the same IP-address
test layout, but it is already between the real ECU and the
extionsions for new transfer functions, which can be select-
messages and MAC address tables, for example. If users
and MAC-address. Conversely, the ECU under test is not
software with the remaining simulated ECU. In practice,
ed and configured appropriately. The interface is therefore
need to perform multiple accesses to the network simulta-
able to address the virtual ECUs separately. It would be
other devices can only be added by establishing new, addi-
extremely flexible to adapt it to the practical challenges of
tional 1-to-1 connections, whereby the new network frag-
different development and test phases. Furthermore,
ments need to be coupled to the existing network via
nearly every network configuration and topology can be
switches. If the interface offers switch functionality inter-
mapped to a functionally identical test setup. If necessary,
nally or could be reconfigured to do so, the colleagues might
the user can configure multiple parallel application chan-
successfully implement their plan and connect the second
nels as well as transfer functions and connect them to the
external ECU to an available port.
Ethernet ports. In addition to switches, transfer functions
can produce usable results.
Figure 3: Data transmission from ECU 1 to ECU 5 via three connections and two switches.
come into consideration, which include “PHY Bypass”
Figure 4: Remaining bus simulation with multiple TCP/IP stacks. In the framework of integration, the simulated ECU 2 is replaced by a real ECU under consideration of the topology.
1/70
The Interface is More Than the Sum of its Ethernet Ports
(mapping on Layer 1) and “MAC Bypass” (store-and-
To adequately meet user requirements, a high-perfor-
forward principle on Layer 2) functions. The interface also
mance Automotive Ethernet interface is equipped with
allows the tools full access to the Ethernet ports at all
numerous ports. Twelve 100BASE-T1 ports are sufficient to
times, either direct or relative, over the application channel.
implement relatively complex test scenarios. But it is not
Native access to Ethernet frames at the bus transceiver
Figure 5: The new flexible VN5640 Automotive Ethernet interface offers 16 Ethernet ports, versatile transfer functions, highly-precise time stamps and extensive filter mechanisms for reducing data volumes.
03
1/71 04
Technical Article / April 2016
during monitoring can reveal problems on the bus such as
interface hardware specially tailored to meet these new
corrupt frames, which are filtered out by the MAC layer in
challenges offers valuable support. In combination with
conventional switches. This enables meaningful analyses
test and simulation tools that have been tuned for the new
that yield findings on what is happening directly on the bus
requirements, this interface hardware will sustainably sim-
and what is arriving at the ECU.
plify and accelerate development and test processes.
Scalable Line of Interfaces for Challenging Automotive
To meet the growing demand for bandwidth, IEEE is
Ethernet Applications
already working on a 1-GBit variant of 1000BASE-T1. Due
Vector Informatik has integrated all of the named func-
to the flexibility in hardware setup the VN5640 interface is
tions and further functions into its new Automotive Ether-
prepared for other physical layers and can be available
net Interface VN5640 (Figure 5). The device was specially
quickly. Technologies such as AVB (Audio Video Bridging)
designed for the application area of simulating or measur-
and TSN (Time Sensitive Networking) will, in the foresee-
ing on the network view level, and it has a total of 16 Ether-
able future, provide for guaranteed worst-case latencies,
net ports: twelve for IEEE 100BASE-T1 and four for stan-
prioritized data transmissions and time synchronism. As
dard Ethernet connections such as 100BASE-TX or
they become available, these and other advanced develop-
1000BASE-T. A very fast host connection routes the enor-
ments will also be implemented in firmware and software
mous quantities of data that can arrive at the Ethernet
updates so that users will always be able to work with
ports. Since generally just a subset of the Ethernet frames
Automotive Ethernet interfaces from Vector Informatik
is relevant for typical test and simulation tasks, the VN5640
that represent state-of-the-art technology.
hardware provides many filter mechanisms that can be activated. Based on the various protocols, the filters only pass the really necessary Ethernet frames to the PC and thereby make a significant contribution toward relieving loads in the simulation and test software. Along with the usual interface mode, the VN5640 can also
Peter Fellmeth (Dipl.-Ing. (FH)) is a group leader and product manager at Vector Informatik GmbH. He is responsible for the development of products for Automotive Ethernet, J1939 and ISOBUS.
be used in stand-alone mode without a PC. In addition, there are future plans for letting the user connect an Ethernet-capable standard automotive data logger. Together with the VN5610 2-port interface, which has already been available for some time now, the VN5640 represents a scalable Automotive Ethernet interface family that works
Matthias Schwedt (Dipl.-Ing. (FH)) is a product manager for network interfaces at Vector Informatik GmbH. In this position he is responsible for the VN5600 Automotive Ethernet interface family.
perfectly with the widely used CANoe test and simulation tool from Vector. In the future, many new functions of the VN5640 will also be supported by the VN5610 and be available after a driver update. All interfaces in this product line can be addressed over a common programming interface (API). In combination with CANoe, users can use description files to conveniently exploit the extensive configuration options. This also offers the advantage of sharing the files with other departments, suppliers and customers. Further-
Translation of a German publication in Elektronik automotive Ethernet edition April 2016 Image rights: Vector Informatik GmbH
more, CANoe offers access to extended statistical and switch information – such as quality information about transmission paths, the contents of MAC address tables and the queue states of switches – which provide useful insights regarding the loads of individual link segments. Conclusion and Outlook The proper methods for developing, testing and simulating Automotive Ethernet networks are generally more difficult than users are accustomed to with CAN, LIN and FlexRay, and the tasks require a differentiated approach. Modern
1/72
05
at the construction zone so that it can modify the speed
precisely match those of real driving situations. By using
limit in the construction zone accordingly or route traffic
test tools, testers do not have to perform complex tests in
jam information to the central traffic control office.
the real environment. In early test phases, it is often impossible to conduct real tests, because not all components are
Onboard Functionality of the Construction Zone
Application
Testing Car2x Applications Requirements for Test Tools Based on Example of the Road Works Warning Carmakers plan to introduce Car2x communication in production vehicles starting in 2015. Car2x application develop-
available. During development and test phases, it is even sufficient to
When a vehicle receives a construction zone specific DENM,
simply provide the application developer with suitable data
it checks the message for relevance. It requires information
from just the communication perspective for testing. This
such as the position, speed and driving direction of the ve-
involves creating a simulated environment for the ECU under
hicle to do this. Ideally, map data that describe the vehicle’s
test in test tools. This ECU can be put in all of the states to
environment more precisely will also be available. This in-
be tested using simulated functions and components.
formation is typically supplied via the in-vehicle bus sys-
This means that a “simulated road works warning trailer” is
tems such as CAN and Ethernet.
needed to test the construction zone application in the
In checking for relevance, information such as the time
vehicle. It can be configured for each individual test so that
stamp lets the vehicle determine whether the received
different scenarios of lane closures and speed limits are
message is still valid. The location of the construction zone
possible, for example, and can serve as the foundation for
and of the vehicle is used to determine whether the con-
tests. In parallel, the construction zone application is stimu
struction zone is located along the driving route. If the
lated with data on a vehicle’s geographic position, direction
message is relevant to the vehicle, the data is forwarded to
vector and speed for each individual test case. The test tool
the actual construction zone application. It ensures, for ex-
also simulates the motion profiles of the vehicle and gener-
ample, that other applications such as driver assistance
ates the related CAN frames for stimulation. Afterwards, it
systems or HMIs are supplied with necessary data when
provides this data to the construction zone application via
the vehicle enters the defined construction zone.
the ECU’s CAN bus interface (Figure 2).
Increasing Efficiency with Test Tools?
Test Tool Requirements for Car2x Applications
To comprehensively test a construction zone application in
For a tool to be used effectively in testing Car2x applica-
the vehicle, application-relevant data for all necessary test
tions, it must fulfill a number of requirements. The test tool
scenarios must be provided to the application, and these
must be able to send and receive WLAN data packets con-
scenarios must
formant to the IEEE802.11p (ITS-G5) standard over the
ment, which has already begun, poses new challenges in the execution of component and application tests. This article derives related requirements for test tools based on the example of the Car2x “Road Works Warning” application.
1/74
Intelligent and safe – that is how the German Transporta-
responsible for packet routing in ad-hoc networks; the in-
tion Minister described the expressways of the future in
formation about the highway construction zone is con-
mid-June of this year. These objectives are to be achieved
tained in standardized application messages [3].
by introducing intelligent transport systems and services
They include the “Decentralized Environmental Notification
(C-ITS, “Cooperative Intelligent Transport Systems”) that
Message” (DENM), which contains all necessary informa-
are based on Car2x communication. What is meant here is
tion about an event (road works warning, end of traffic jam
communication between vehicles and the infrastructure
warning, etc.) and is only sent at the onset of the relevant
with the aims of improved safety on roads and early avoid-
event. Here, the ITS station transmits general information
ance of traffic jams. As a first step, warning trailers will be
about event status and position and about the applicable
equipped with the necessary Car2x technology for radio
duration and zone. For the Car2x “Road Works Warning”
transmission of road works information to vehicles.
application, the warning trailer also sends information on the
The scenario of the Road Works Warning is one of the
speed limit and lane closures, which are dynamically modified
Car2x applications already defined by the European Tele-
as a function of construction zone status and topology.
communications Standards Institute (ETSI) [1], and plans
The ITS stations use the “Cooperative Awareness Message”
call for technically implementing it starting in 2015. Here,
(CAM) to periodically transmit their own status informa-
the warning trailer sends its information in real time to
tion such as position and driving direction, speed and accel-
vehicles within WLAN radio range per the WLAN standard
eration information as well as status information about
IEEE802.11p (ITS-G5) (Figure 1). A 5.9 GHz frequency band
the vehicle lighting of the ITS station. Since all ITS stations
is available, which was specifically reserved for ITS-G5
send this information, the information lets the warning
usage. The GeoNetworking protocol specified by ETSI [2] is
trailer perform such tasks as calculating the traffic density
Figure 1: Simplified representation of communication in a construction zone scenario.
1/75
Testing Car2x Applications
WLAN channels defined for this purpose. This includes the
cated and modified for other test scenarios. Test flow con-
works such as CAN, FlexRay and Ethernet, tests can also be
test tool’s ability to interpret
trol then handles execution of the selected tests and docu-
developed for the Car2x environment. They assist in devel-
protocol-specific information such as GeoNetworking. It
mentation of the results in a test report.
oping and integrating Car2x technology in vehicles and in
must be possible to access signals and data fields of the
Since a lot of geographical positions are processed in the
the infrastructure. With the signing of the Memorandum of
application messages, which are described in ASN.1 (Ab-
Car2x environment, it is extremely helpful to visualize them
Understanding initiated by the CAR 2 CAR Communication
stract Syntax Notation.1) and are coded by the PER meth-
on a map. Information from the DENM is also intrepreted
Consortium [4] Vector is assuring its customers that future
od (Packed Encoding Rules). A description of this informa-
and displayed on this map (Figure 3). At a glance this
test tool requirements will be implemented as well.
tion in a database that the test tool can read offers maxi-
makes it easy to see exactly where the construction zone
mum flexibility here and simplifies the process of modifying
and vehicle are located, whether the relevance zones and
Translation of a German publication in Automobil-Elektronik,
data if changes are necessary. The database description
waypoints are coded correctly, and what information is
6/2013
serves here as the foundation for test generation. Using a
transmitted in the message regarding lane closures.
database approach for creating and executing tests has
The construction zone application, or the ECU, obtains this
Image rights:
already proven itself in established automotive networks.
information via internal vehicle networks such as CAN and
Vector Informatik GmbH
In order to use an environmental simulation for stimulation
Ethernet and externally via ITS-G5. Therefore, the test tool
purposes during the test, a programming tool is needed to
must support this process as well as offer multibus capability.
create simulated nodes. Ideally, the tool would offer a
Thomas Löffler (Graduate Engineer) is group leader and product manager for the ITS/Car2x area at Vector Informatik GmbH.
Cathleen Kunze (Graduate Engineer) works as a technical writer for Car2x at Vector Informatik GmbH.
Literature references: [1] ETSI TR 102 638 V1.1.1 (2009-06)
Car2x-specific function library, which makes it possible to
Summary
[2] ETSI EN 302 636-1 V1.1.0 (2010-03)
create and send application messages, set and read their
Car2x technology is not only being studied in the research
[3] ETSI TS 102 637-2 V1.2.1 (2011-03), ETSI TS 102 637-3
signals and data fields, and execute PER coding of data be-
departments of OEMs, but also by production develop-
V1.1.1 (2010-09)
fore sending. Functions for generating UTC time stamps,
ment departments are now exploring how this technology
[4] Memorandum of Understanding, CAR 2 CAR Communi-
which are frequently needed in the Car2x environment are
might offer added value and how it might be used to better
cation Consortium, Version 4.01.02 (2011-06-27)
helpful too. This makes it possible to configure valid con-
support driver assistance systems. The quality of these
struction zone specific DENMs for each individual test case.
new functions must be assured by suitable test tools.
Links:
An integrated test environment simplifies test execution.
At this point, Vector supports the introduction of this tech-
Vector solutions for Car2x:
The tests are created with the help of editors and
nology in production vehicles with its CANoe .Car2x devel-
www.vector.com/vi_car2x_solutions_en.html
Car2x-specific function libraries and can simply be dupli-
opment and test tool. Along with tests for automotive net-
Product information CANoe .Car2x: www.vector.com/vi_canoe_car2x_en.html
Figure 2: Schematic layout of a Car2x test scenario: The construction zone warning application is stimulated by the test tool to test functionality in various scenarios.
1/76
Figure 3: The entire test scenario can be implemented and visualized in CANoe .Car2x. Clear representation of the ITS stations in the map window with a display of the driving direction.
1/77
dating the ITS-S are derived from the example of a Car2x
to be updated at a rate of 10 Hz. However, the latency time
scenario defined by ETSI [1]. Similar traffic scenarios are
for the above scenario is specified as less than 100 ms [1].
described in the CAR 2 CAR Communication Consortium
This makes transmission via GSM unrealistic. The real-time
and in the DRIVE C2X project [2].
requirement can only be satisfied with WLAN technology
In the “Car Breakdown Warning” scenario, the goal is to
per IEEE 802.11p or LTE, and LTE cannot be considered cur-
avoid having a broken down vehicle pose a hazard to ap-
rently due to its low coverage.
proaching traffic or even cause an accident. Therefore, the
The ITS-S units in vehicles within the reception area must
ITS-S of vehicle A sends a standardized message that can
first decide whether received messages are relevant to
be received within its WLAN transmission range (Figure 1).
their own vehicles; i.e. whether they are affected, and
An approaching vehicle B receives and processes this mes-
whether they should forward them. They are affected if
sage and forwards it. This extends the WLAN transmission
they are located on the same street or on the way towards
range so that even further distant vehicles C and beacons
that street. This can be determined by the “heading” mes-
(Road Side Units – RSU) can receive the message and for-
sage contents of the received CAM message and “way-
ward it. This gives vehicle C enough early notice to avoid
points” in the DENM message. Other factors playing a role
the hazard area by choosing an alternate route. Thanks to
here are the route of the specific vehicle and information on
the early warning, vehicle B can brake in time, e.g. when the
the topology and status of traffic light systems. Finally, the
view is impaired by fog or by obstacles such as a curve with
ITS-S units must evaluate whether the information is po-
limited visibility.
tentially relevant to other units in the environment. If so, it
To assure that information is current and to avoid faulty
must route the information correctly.
information, a distinction is made of whether the message is coming from the original source A, or whether it was just
Requirements for Validating ITS-Stations
forwarded by another sender (receiving vehicles B, C). Since
Software development tools can support the system man-
forwarded messages have a limited life, they are only routed
ager in all phases of the V-model to assure functionality of the
for a specific time period. Based on geo-positioning and a
ITS-S. Unlike network development that is limited to a single
Car2x – From Research to Product Development
defined dissemination area, a decision is also made regard-
vehicle, here it is absolutely necessary to consider the environ-
ing whether vehicles B or C should forward the message at all.
ment. This yields the following requirements for the tool.
How Automotive OEMs and Suppliers are Successfully Completing Production Car2x Projects
Requirements of the ITS-Station in the “Vehicle Break-
Debugging of the Air Interface
down” Scenario
In terms of measurement technology, the scenario described
Car2x systems present entirely new challenges for managers in product development departments. For one, the Car2x
The ITS-S must derive a sufficiently complete picture of the
above can be reduced to Figure 2, possibly with a greater
ECU under study must communicate with a large number of vehicles and beacons in its environment. This increases the number of information exchanges and their complexity compared to previous network development in production vehicles. For another, IP standards have now made their way into the vehicle; however, this is uncharted territory for most developers using the IEEE 802.11p air interface. These challenges can already be overcome with tools that are adapted to this interface.
Car2x communication (also known as Vehicle-to-Vehicle
Awareness Message), DENM (Decentralized Environmen-
and Vehicle-to-Infrastructure communication) is the ex-
tal Notification Message), SPaT (Signal Phase and Time)
change of information between traffic participants and
and TOPO (Topology Specification). The European Insti-
the infrastructure with the goal of enhancing safety and
tute for Telecommunication Standards (ETSI) has already
convenience and optimizing traffic flow. The higher-level
specified the CAM and DENM messages. SPaT and TOPO
engineering system for assuring Car2x communication is
are currently handled on a project-by-project basis. This
known as the Intelligent Transport System (ITS). The basic
system gives the intelligent processing units (ITS-S) of the
concept of Car2x communication involves sending and re-
receiving traffic participants, e.g. a vehicle, the opportunity
ceiving standardized messages over the air interface and
to acquire information about the immediately relevant
enabling interpretation of the status information they con-
traffic situation over a broad area and to warn the vehicle
tain by traffic participants. The ITS station (ITS-S) keeps
driver if necessary or even intervene in vehicle control.
traffic situation from the context of its surroundings, i.e.
number of ITS stations. The functionality of the ITS-S is in-
the totality of the CAM, DENM, SPaT and TOPO messages
deed standardized, but it is implemented by different manu-
obtained from various sources, and it must initiate actions
facturers. In case of error, it is often first necessary to de-
for its own vehicle. Real-time requirements are high here.
termine whether all participants are sending and receiving
Per specification, DENMs of the above example only need
on the same radio channel. This requires support of the air
the messages up-to-date based on the momentary traffic
1/78
situation and sends them either periodically or they are
Scenario of the Broken Down Vehicle
event-driven. The most important status information is
In the following, the requirements of development tools
transmitted via the message types CAM (Cooperative
that support the system manager in developing and vali-
Figure 1: Vehicle A is at a standstill, and it sends DENM messages via its ITS-S to traffic participants B in its local surroundings. They extend the transmission range by forwarding the message to other vehicles C and roadside units D.
1/79
Car2x – From Research to Product Development
Figure 2: Challenge of the air interface: The data traffic can only be checked with an IEEE 802.11p compatible analysis tool.
ing tests, e.g. at the test site in Helmond, Netherlands [3],
Stimulation and Simulation
and has already proven its value in integration support at
Even with functioning prototypes, there is often a wish to
the ITS World Congress [4] in Vienna. The evaluation is
actively participate in the communication, e.g. to send indi-
greatly reduced for the developer if identifying supplemen-
vidual CAM, DENM, SPaT or TOPO messages correctly or
tal information is assigned by the senders, such as make,
as corrupted messages. This lets the Car2x developer to
vehicle type, model or license plate. Intuitive symbols and
test first prototypes by targeted stimulation very efficient-
color codes provide an easy to understand overview of the
ly. However, the development tool must be able to send
traffic situation. For example, mobile senders are depicted
messages conformant to the protocol and the air interface.
on the map in Figure 3 as arrows, waypoints as flags and
On test drives, it is helpful to show RSUs or other vehicles
RSUs as circles. In contrast to the pure protocol represen-
that do not exist in real form with the map representation
tation of Figure 4, problems with incorrectly sent driving
introduced previously. Then the development tool can as-
directions (“headings”) can be detected immediately here.
sume the role of individual traffic participants on the test
In addition, it is possible to show topographic information
drive, or even all participants, and can also simulate their
(TOPO) on the map as well as hazard information (DENM),
communication over the air interface. On the test drive, the
which also plays a role in many scenarios.
ITS-S is no longer able to determine whether received Car2x signals originate from real sources or from the simulation. This assumes that separate software models can be saved separately for all traffic participants and that they can
interface as a communication medium. Only if it can be ver-
Visualization of the Vehicle Signal on a Geographic Map
In practice, it is very helpful if the test system can immedi-
ified that communication over the air interface is operating
Unfortunately, even interpreted representation of message
ately show the entire data traffic without a long setup
then be individually activated and associated with the map
correctly does it make sense to conduct a protocol analysis.
contents with filtering is often inadequate due to the num-
time. Here, knowledge of the underlying data model is nec-
display.
ber of traffic participants and the complexity of the com-
essary, which is usually defined by ASN.1 (Abstract Syntax
Protocol Analysis
munication. Important data must be recognized immedi-
Notation). Nonetheless, ASN.1 cannot represent any networks,
Compatibility to Development Strategy for Previous Bus
The ITS-S system testing manager in product development
ately, even if it is not obvious from the set of interpreted
and it lacks the desired ability to manage signals with physical
Systems
needs to have the received message contents presented in
information.
units. Therefore, the analysis and development tool must
Today’s vehicle networks are based on CAN, FlexRay, LIN,
an application-oriented way in the development tool, i.e.
The scenario described above illustrates how the relevance
permit easy parameterization of this information that is
MOST and most recently IP (Internet Protocol) as well, e.g.
either as physical parameters (with units) or interpreted.
of a Car2x signal for the receiving vehicle can only be deter-
supplemental to the ASN.1 description. The ASN.1 file, on
in the form of BroadR-Reach technology [5]. The method of
For example, the signal “Generation Time” (in CAM and
mined in the context of other traffic participants in its rel-
the other hand, should ideally be automatically importable.
remaining bus simulation is typically used to develop indi-
DENM) is expressed with units and the CAM signal “Vehicle
evant environment and can therefore only be validated in
This ensures, for example, that if communication rules
vidual ECUs. It makes it possible to develop ECUs in parallel
Type” is interpreted, e.g. as a “Car“ or “Motorcycle”. Similar
this context. For validation, the geo-positions and heading
change due to updates, the new signal values are immedi-
and independent of one another. The network hardware
examples are the DENM signal “EventPosition” (with lati-
vectors of the participating vehicles must be taken into
ately available in the tool without having to perform another
that is relevant to the ECU under test, but is not yet avail-
tude and longitude, i.e. values with units) and the signal
consideration. A map representation is recommended,
step such as recompilation.
able, is simulated in software by the development tool.
“Cause Code” (interpreted).
which can clarify the relevance (Figure 3) in practical driv-
Figure 3: On the map, vehicles are depicted by direction arrows and RSUs by circles. The hazard information transmitted in the DENM (e.g. OW – Obstacle Warning) and the waypoints that lead to this hazard point are depicted as well as the dissemination range of the message for this hazard.
1/80
Immediate Availability and Quick Reconfiguration
Since the ITS-S is generally also a participant in one of the
Figure 4: Protocol representation of Car2x information in the CANoe and CANalyzer trace window.
1/81
Car2x – From Research to Product Development
above named vehicle buses, remaining bus simulation is also a useful method here.
out either correct or corrupted pWLAN packets for test
The map window (Figure 3) makes an important contribu-
purposes. For more complex simulations of traffic scenarios
tion to the analysis. The next development step might be to
with vehicles and the infrastructure, the Car2x developer
use this map to define scenarios and constraints on the be-
Development Tools for Car2x Communication
uses specific function libraries prepared in CAPL or as
havior of the simulated traffic participants. A radio adapter
What are the implications of the necessary Car2x exten-
a DLL.
already installed in the vehicle could be used as the 802.11p
sions for a development and validation tool for production
CANalyzer .Car2x covers the most important requirements
WLAN interface hardware for communication between ve-
implementation?
of a Car2x development tool such as protocol analysis,
hicles or between a vehicle and the infrastructure. It could
The key to a solution is to combine the approaches de-
support of the air interface and stimulation. Visualization
be used together with the vehicle application or exclusively
scribed above with the usual practice-proven methods of
and quick reconfiguration capabilities also increase the
as a measurement interface. This is a pragmatic and flexi-
conventional network development in the automotive in-
usability of the development tool substantially. In addition,
ble solution for many application cases. However, the mea-
dustry. CANoe and CANalyzer have thoroughly proven their
CANoe .Car2x extends the tool’s range of use to include
surement precision of this radio adapter might be inade-
capabilities as multibus tools for developing onboard net-
many different simulations and test functions.
quate for some tasks. Consequently, there is some debate over whether even more precise, further advanced mea-
works based on CAN, LIN, FlexRay, MOST and Ethernet. Option “Car2x” extends these tools for the development of
Outlook
convenience and driver assistance functions. This involves
Future driver assistance systems based on ITS-S will have
extending the simulation setup shown in Figure 5 by adding
to incorporate additional vehicle dynamic data that sup-
Translation of a German publication in Elektronik automotive,
the air interface. If necessary, the test system can substi-
plements the Car2x communication, and this supplemental
12/2012
tute for the entire environment of the ITS-S and can both
data is available on CAN, FlexRay or IP networks in the ve-
send and receive. In this approach, the above named re-
hicle. It is therefore increasingly important for the develop-
Literature:
quirements of protocol analysis, quick reconfiguration and
ment system to be able to represent both the Car2x com-
[1] ETSI, Intelligent Transport Systems (ITS); Vehicular
visualization are already considered in a map view.
munication and communication on conventional bus sys-
Communications; Basic Set of Applications; Definitions,
The WLAN Packet Builder with its intuitive user interface
tems with high timestamp accuracy and over multiple
ETSI TR 102 638 V1.1.1 (2009-06)
can be used to intentionally send faulty information for
channels. CANoe .Car2x and CANalyzer .Car2x are already
[2] CAR 2 CAR Communication Consortium, Related Proj-
validation purposes. It makes it easy to create and send
equipped for these tasks today.
ects, www.car-to-car.org/index.php?id=6&L=oksjfr
surement hardware might be made available in the future.
[3] Making cooperative systems cooperate, DRIVE C2X @ DITCM Helmond, NL, www.drive-c2x.eu/news-item/items/ drive-c2x-ditcm-making-cooperative-systems-cooperate [4] ITS World Congress, Vienna, http://2012.itsworldcongress.com [5] Schaal, H.-W.: Ethernet and IP in motor vehicles, Elektronik automotive. Issue 4/2012, pp. 38ff. Links: Vector solutions for Car2x: www.vector.com/vi_car2x_solutions_en.html Product information CANoe.Car2x: www.vector.com/vi_canoe_car2x_en.html Hans-Werner Schaal (Graduate Engineer) is Business Development Manager in the areas of Automotive Ethernet, Car2x and open CAN protocols such as J1939 and ISO11783 at Vector Informatik GmbH.
Figure 5: ITS-S test system: If necessary, the test system can substitute for the entire environment of the ITS-Station and can both send and receive. The usual simulation setup is extended by adding the air interface. As in a realistic situation, the ITS-S can communicate via the air interface and local bus systems.
1/82
Thomas Löffler (Graduate Engineer) is Senior Software Development Engineer at Vector Informatik GmbH working in the area of Car2x. His areas of focus are product definition and project management of customer projects. Mr. Löffler also represents Vector on a number of Car2x standardization committees.
1/83
More Stringent Requirements for Test Hardware A basic prerequisite for any diagnostic or test process is a suitable interface hardware, which produces the connection between the diagnostic PC and the device under test. It is possible to use a PC’s conventional UART/RS232 interface to test K-Line devices, but this method quickly encounters limitations. It lacks the advanced properties that are needed to check for conformity and to verify correct functionality. This also requires knowledge of how close the DUT is to operating at its specified limits, or expressed differFigure 1: Different K-Line interfaces: from single-channel USB interface to HiL module
ently, the size of its functional reserves. In contrast to RS232 solutions, efficient K-Line interfaces enable precise acquisition of communication timing. Both sent and received K-Line frames are provided with exact time stamps. They also offer automatic detection of baud
byte at five baud, and the receiver detects this slow trans-
rates – including fast initializations and 5-baud initializa-
mission rate. Also characteristic of the K-Line are special
tions – and it is also possible to manipulate K-Line timing
Key Bytes that are used to identify header formats and
and data and to send raw byte streams. These interfaces
timing parameters.
can be connected to any PC via USB, and they work togeth-
One important task of automotive OEMs in the after-sales
er with software tools ideally, e.g. over a specialized K-Line
market is to support the service of all K-Line vehicles world-
API, which enables easy access to all hardware functions in
wide by providing service shops with suitable K-Line tes-
test scripts.
ters. In ECU development with K-Line, new functions are
K-Line: Flexible Solutions for a Classic protocol From Precise Monitoring to Data Manipulation for Generic Byte Protocols
provided that need to be tested. Therefore, manufacturers
Scalable K-Line Solutions
and suppliers need powerful hardware and software tools
Vector offers a product line-up of K-Line components that
that support the K-Line protocol for K-Line test equipment
are tuned to one another for the purpose of testing and
and ECUs.
simulating K-Line-developments; these components con-
In the past, the K-Line diagnostic protocol was the standard for diagnostic tasks in various vehicles, and it is still used widely used today. The age of this interface has not made it obsolete in today’s diagnostics, development projects and The K-Line diagnostic protocol no longer plays a substantial role in new developments, because systems such as CAN and Ethernet have long taken over diagnostic tasks once performed by the K-Line. Nonetheless, automotive OEMs, suppliers and service shops worldwide cannot overlook the fact that many vehicles and ECUs still use K-Line technology, and this will remain the situation for some time. ECUs with a K-Line interface are still used in passenger cars, the truck sector and in motorcycles.
Those Presumed Dead Live Longer
face, it is based on the technology of typical UART (Univer-
Millions of passenger cars and motorcycles with K-Line
sal Asynchronous Receiver Transmitter) circuits. In asyn-
technology are still driving on the roads, especially in mar-
chronous transmission, the sender and receiver use start
kets such as China, India and South Asia. They are generally
and stop bits for synchronization purposes. This means
vehicles whose level of technology is outdated by around
that the system does not need a supplemental clock line,
10 to 15 years. Many European vehicle developments of
and a single-wire line suffices. In contrast to RS232, the
that time were and are still being built in Asia under license,
K-Line – like a bus system – enables communication with
although their production ceased many years ago here. It is
different ECUs by addressing them. The standard trans-
still the usual practice – especially in cases of smaller pro-
mission rate is 10,400 baud, and speeds up to 115.2 kbaud
duction volumes – to continue to use proven ECU develop-
are used for such purposes as programming of flash
ments in subsequent or related product lines, and this too
memories.
has extended the life of the K-Line.
The K-Line is suitable for both on-board and off-board diagnostics, and it offers two special initialization patterns:
1/84
Serial UART Diagnostic Protocol with Bus Characteristic
Fast-Init is based on a 10,400 baud standard, and it sends
The K-Line is a diagnostic protocol that conforms to the
a wake-up pattern. There is also what is known as the
ISO 14230 standard. Like the standard RS232 serial inter-
5-Baud Init pattern, in which the system sends an address
Figure 2: K-Line test and simulation environment
1/85
sist of high-quality interface hardware and high-perfor-
and analysis windows display timing, baud rates, header
mance software tools. The solutions cover all conceivable
bytes, useful data, inter-byte and inter-frame spaces with
requirements and are flexibly scalable – from a single-chan-
high precision (Figure 3). Other windows permit interactive
nel K-Line monitoring tool to solutions that enable simula-
sending of K-Line frames. The application programming
tion of K-Line diagnostic testers and ECUs, and finally large
language, CAPL, can be used to send raw frames and inject
HIL systems. The latter are characterized by such aspects
errors. Simulations can also be created with CAPL in con-
as real-time properties, and they can simulate multi-chan-
junction with a special K-Line API. Test modules then pro-
nel ECU environments for test runs, in which other bus sys-
duce the automatic test sequences and generate reports.
tems such as CAN, LIN and FlexRay can be integrated along with K-Line. Vector can supply various types of interfaces
Summary
for connecting to K-Line – via a USB interface or PCI bus.
High-performance and modern tools are also available for
They include the VN1600 and VN8900 interface products
the K-Line protocol, which has certainly aged over the
as well as plug-in cards such as the VN7570 and the VT6204
years, but is still used for such purposes as maintenance of
for the VT System (Figure 1). The 7269 LIN transceiver,
diagnostic testers and ECUs. They not only give automotive
which offers optimal K-Line support, handles transmission
OEMs and suppliers qualified tests at a high level of quali-
on the physical level.
ty; they also enable troublefree advanced development and reuse of existing K-Line components.
Support of Proprietary K-Line Variants and Byte Protocols
Reprint of the online publication in Automotive EE Times
CANoe and CANalyzer are two alternative software tools
Europe, May 2015
that are available from Vector. While CANoe represents the universal solution for (automated) tests and simula-
Image rights:
tions, the focus of CANalyzer is on analysis and monitoring
Vector Informatik GmbH
tasks (Figure 2). These tools permit access to all K-Line parameters and settings. Testing personnel can conduct the tests, measurements and injection of errors on different levels: on the diagnostic and communication levels and – a unique capability – on the byte level. This makes the tools usable for proprietary K-Line variants that deviate from the standard as well as generic serial byte protocols. Trace
Figure 3: K-Line analysis on different communication levels
1/86
Peter Decker has worked at Vector since 2002 where he is currently Product Manager in the Networks and Distributed Systems product line.
Figure 1: Structure of a MOST device that among other things hosts the “Audio Disk Player” functional block. For system management, the Net Block is mandatory for each MOST device, and system functions are mandatory for each function block.
Serial Bus Systems in the Automobile
MOST for Transmission of Multimedia Data existence since October 2006. It is organized into the areas
Hierarchical Communication Model
of Application, Network and Hardware.
MOST systems are patterned on a three-stage hierarchical
The “Application” area describes a logical device model
control philosophy based on the “Master-Slave principle”
based primarily on object-oriented methods, with the pur-
(Figure 2). Placed at the uppermost hierarchical level is the
pose of transparent modeling and control of distributed
HMI (Human Machine Interface), an exposed controller
infotainment systems. Furthermore, it defines a hierarchi-
that provides the user with overall functionality. On the
A premium class car is growing to resemble a mobile office. In response to customer demand, increasing numbers of enter-
cal communication model as well as services for managing
middle hierarchical level are the usual controllers. They cov-
tainment and information media that are making their way into automobiles. The most significant challenges in this area
an infotainment system. The “Network section” describes
er part of the system functionality, and they share their
are, first, to keep wiring expense as low as possible, and second, to fully satisfy the heightened functional requirements of an
the MOST Network Interface Controller and its services,
partial system knowledge with the HMI as the “System
infotainment system in the car. As a result, the MOST (Media Oriented System Transport) bus system is now used to trans-
network management, and handling of data transport in a
Master”.
mit audio and video signals in approx. 50 model series.
MOST system. The “Hardware section” deals with aspects
The lowermost hierarchical level is made up of the system
of the hardware structure of a MOST device.
slaves, whose functions are used by one or more controllers. They are not equipped with any system knowledge,
The already extensive wiring cost and effort are increasing
Functional Modeling
and this substantially enhances their flexibility with regard
safety and convenience functions in automotive technolo-
due to continual growth in networking of continually higher
A MOST device is subdivided into a functional level and a
to configuration. It is easy to add system slaves or remove
gy. Experts predict that in just a few years electronics will
performance infotainment devices of dimensions that can
network level (MOST Network Interface). On the functional
them from a MOST system. MOST commands are used for
represent a share of up to 30 percent of vehicle value, and
hardly be managed any longer. Fortunately, some automo-
level, infotainment functionalities are embodied in so-
control communication. Their core components are the
the worldwide market for electronics in cars will grow by
tive OEMs recognized the advantages that bus networking
called function blocks. Each function block, e.g. the Audio
FBlockID, FktID, Operation Type and up to 65535 useful
approx. 6 percent annually to 230 billion euros by the year
would also offer in this area early on. In the mid-1990s,
Disk Player, provides the MOST network with a dedicated
bytes.
2015. The automotive industry is forecast to exhibit rapid
BMW and Daimler began to develop a uniform communi-
set of functions, e.g. “Track position”, that can be accessed
growth rates, above all in the infotainment area, given the
cation technology for serial transmission of audio and video
by operation types such as “Set” for setting a track or “Set-
continually increasing vehicle-kilometers on Germany’s
signals in the vehicle based on the D2B bus (Digital Data
Get” for setting and reading a track (Figure 1).
roads (according to DIW [1] approx. 700 billion). The aver-
Bus) developed by Matsushita and Philips.
Functional addresses (FBlockID, FktID) are assigned to
Electronics is responsible for a large number of innovative
both the function blocks and to the functions provided by a
age citizen spends about 270 hours in a car annually,
1/88
whether it is on the way to work, shopping or vacation.
MOST Cooperation
function block. They can be taken from the so-called “Func-
Over the course of time, the car radio was supplemented by
In 1998, BMW, Daimler, Harman/Becker and SMSC (for-
tion Catalog”, as can the identifiers of the operation types.
the CD and MP3 player. This came to include CD changers
merly OASIS SiliconSystems) founded the MOST Coopera-
For example, the “Audio Disk Player” FBlock has FBlock-
and navigation devices, and finally display screens also
tion [2]. Since that time, MOST has established itself as a
ID=0x31 and the “Track Position” function has FktID=0x202.
made their way into cars for replaying DVD and video films.
de-facto standard for the transmission of multimedia data
The separation of function and network and functional
Moreover, hands-free Bluetooth units with integrated mi-
in the vehicle – the MOST Cooperation is made up of 15 in-
modeling make it possible to implement a functional com-
crophones and iPod control are gradually turning the cock-
ternational automotive OEMs and more than 70 device
munication model that is fully independent of physical
pit a multimedia center, in which all of the play lists and
producers. The user organization laid the foundation for
components (MOST devices). Therefore, it does not matter
directories of a digital MP3 player can be displayed and
success of the technology by defining an extensive specifi-
which of the MOST devices is used to contain a specific
started directly on the in-vehicle display.
cation. Version 2.5 of the MOST specification has been in
function.
Figure 2: Hierarchy of a MOST system
1/89
Serial Bus Systems in the Automobile
FBlockIDs function (FktID=0x000). The FktIDs 0x002,
the load of the EHC. For control, the INIC provides the EHC
tion table”. The CM passes the addresses of the allocated
0x003 and 0x004 are used to find the physical address,
or MOST API (MOST Network Services) with a functional
streaming channels to the data sink, e.g. to the display, so
logical address and group address of a MOST device.
interface, the so-called INIC-API. The functions of the INIC
that it can connect to the streaming channels. Finally, the
The Network Master plays an important role in the man-
are encapsulated in a function block (FBlock INIC).
CM updates the “sync connection table”, which it uses to
agement of a MOST system. It is responsible for the system start and management of the “Central Registry”. This
MOST Networking
formed according to the same scheme.
registry contains the logical addresses of the MOST devices
MOST technology enables transmission of continuous bit
To enable transmission of data packets, the user has the
implemented in a MOST system and the addresses of func-
streams (bit streaming) without buffering or unnecessary
option of reducing the number of streaming channels by up
tion blocks contained in the MOST devices.
overhead. This involves having a specially designated MOST
to 24 (six quadlets) using the “Boundary Descriptor”. All
device (Timing Master) feed the MOST frame (Figure 4) at
those streaming channels that are not reserved for bit
MOST Network Interface
a fixed frequency (44.1 KHz or 48 KHz) into the transmis-
streaming, are combined to form the packet channel. While
The MOST Network Interface (Figure 3) ensures that the
sion medium, which is typically optical.
a maximum transmission rate of up to 12.7 MBit/s is possi-
function blocks housed on the various MOST devices are
In a MOST25 system, the MOST frame provides 60 stream-
ble at a frequency of 44.1 KHz, a maximum rate of up to
capable of real communication with one another. The
ing channels at 8 bits (or 15 quadlets of 4 bytes each) for
13.8 MBit/s is attained at 48 KHz. The boundary descriptor
MOST System Services (Low Level System and MOST Net-
transmission of continuous bit streams (source data area).
is managed by the Network Master function block (FBlock-
work Services) provide the communication functionalities
The bandwidth of a streaming channel yields either 352.8
ID=0x02). It can be set via the “Boundary” function
needed
KBit/s (44.1 KHz) or 384 KBit/s (48 KHz).
(FktId=0xA03).
(time-continuous bit streams, packet data and control
Since the MOST devices are physically interconnected into
A Layer 2 protocol is used to transmit data packets. The
data). Low Level System Services (Layer 2 services) are im-
a ring, each MOST frame must pass through every MOST
frame comprises the arbitration field, source and target
plemented in hardware (Network Interface Controller –
device at the frequency prescribed by the Timing Master. As
address, data length code, data field (either 48 or 1014 byte)
NIC) and are placed over the Physical Layer.
soon as the relevant communication partners (data source
and data protection. A token circulating in the ring regu-
The Application section defines higher-level function blocks
MOST Network Services, which encompass the Transport
and sink) have connected to the same streaming channel,
lates bus access. The MOST device that takes the token
and functions for system management. System functions
Layer in the form of Basic Layer System Services and high-
bit streaming begins (Figure 5).
from the ring may access the packet channel.
include the “FktIDs” function (FktID=0x000) that is used
er management in the form of an application socket, are
Connection or disconnection is usually made by a query by
Finally, the MOST system must transmit the MOST com-
to query the functions supported by a function block, for
housed on an external Host Controller (EHC) and control
the function block “Connection Master – CM” (Fblock-
mands needed for management and control. Control mes-
example. The “Notification” system function (FktID=0x001),
the NIC. It must be ensured that the EHC can serve the
ID=0x03). For this purpose, the CM provides the two func-
sages (Figure 6) are used here, which are transmitted on
on the other hand, enables creation of the “notification
time-critical parts of the Network Interface. Over time,
tions “BuildSyncConnection” and “RemoveSyncConnection”.
the control channel (2 bytes). Therefore, 16 MOST frames
matrix” for a function block. Emerging from the “notifica-
with the progressive development of MOST technology
In the framework of building a connection, the CM requests
(MOST block) are required to transmit a control message.
tion matrix” is information on which MOST device should
from MOST 25 to MOST 50 and MOST 150, this architec-
that the relevant data source, e.g. the TV tuner, have the
The bandwidth at 44.1 KHz is 705.6 KBit/s, and at 48 KHz it
be notified if a certain property of a function block has
ture has now encountered its limits.
suitable number of streaming channels allocated by the
is 768 KBit/s. Transmission of control messages is also
changed. This mechanism prevents an unnecessary in-
In new developments, INIC (Intelligent Network Interface
Timing Master. That is because the Timing Master is re-
based on a Layer 2 protocol. Bus access is implemented by
crease in bus load in the MOST system.
Controller) replaces NIC. While INIC assumes control of ex-
sponsible for management of the “channel resource alloca-
the CSMA method (Carrier Sense Multiple Access).
To query its function blocks and addresses, each MOST de-
ecution of time-critical portions of the network driver of
vice has the “Net Block” (system) function block with
the EHC, just a relatively small part of the network driver
FBlockID=0x01. The function blocks can learn about the
still runs on the EHC, which essentially represents a socket
function blocks implemented on a MOST device using the
for the application. The INIC architecture thereby relieves
Figure 3: Difference between NIC and INIC architectures in a MOST device
System Management
to
transport
all
multimedia
relevant
data
Figure 4: Layout of the MOST frame: Sent in administrative byte 0 are synchronization information and the boundary descriptor, and in administrative byte 63 the status bits and a parity bit for protection of the MOST frame.
1/90
manage all synchronous connections. Disconnection is per-
Figure 5: Principle of bit streaming: The Timing Master transmits MOST frames at a frequency of 48 KHz. 40 streaming channels (10 quadlets) are available for allocation, each operating at 384 KBit/s (boundary descriptor = 0xA). The packet channel (20 bytes) provides a bandwidth of 7.68 MBit/s for the transmission of data packets.
1/91
Serial Bus Systems in the Automobile
Physical Layer Today, optical conductors of polymer fibers (POF – polymer optical fiber) are the state-of-the-art technology for transmitting audio and video signals in the MOST system (Figure 7). Overall, the technical properties of polymer fibers are far superior to those of electrical transmission media. Especially noteworthy are its excellent electromagnetic immunity and relatively high signal transmission rate of up to 500 MBit/s. Furthermore, the combination of POF, a red light-emitting diode as the light source (wavelength 650 nm) and a silicon PIN photodiode as the receiver represents a Figure 6: Control message. A MOST block is required to transmit a control message. The control message is composed of: arbitration (a), target address (b), source address (c), message type (d), data field (e), data protection (f), acknowledgment (g), and reservation (h).
very economical and comparatively simple and manageable form of optical signal transmission. MOST 150, which follows MOST 50, is a MOST system that is current ready to start. It is based on this sender and receiver technology and offers the user a transmission rate of 150 MBit/s. It can therefore handle the relatively short paths in the car of up to 20 meters can without any problems. Development, Testing and Analysis of MOST Systems Vector Informatik GmbH has been an associate member of the MOST Cooperation since 1999. Besides its extensive activities in the area of serial bus systems such as CAN, FlexRay and LIN, the Stuttgart-based networking specialist has been supporting the development and analysis of info-
Background knowledge on signal transmission in a MOST system via POF primary axis is the optically denser medium. In the transition from the optically denser to the optically less dense medium, the beam is refracted away from the primary axis. The angle of refraction a can be calculated if the so-called indices of refraction n of the two media are known (Snellius Law). If the light beam exceeds an incidence angle a0 in the transition from the optically denser medium to the optically less dense medium, then total reflection occurs. This property makes it possible to transport light in an optical conductor. In the MOST system, polymer fibers are usually implemented for optical signal transmission, where a core of PMMA (polymethylmethacrylate) is encased in a thin sheath of fluorinated acrylate. PMMA has a larger refractive index than the fluorinated polymer. If the angle of the incident light beam is greater than the limit angle, then the light is conducted in the core due to total reflection. The smallest attenuations for transmission of light in a When a light beam passes from one transparent medi-
so-called step-index PMMA fiber are obtained at 520 nm
um to another, it is refracted. The greater the angle of
(green), 560 nm (yellow) and 650 nm (red). Red LEDs
incidence, the greater the refraction. The medium in
are generally used (attenuation 0.14 dB/m), since they
which the light beam forms a smaller angle with the
are very inexpensive.
tainment solutions in the automobile since the year 2000. It offers a comprehensive product lineup of analysis, development and test tools for applications such as high-end audio systems, multimedia streaming, telephone and navigation. Hardware interfaces for bus access, a multibus data logger as well as training courses and engineering and development services round out its offering [3]. The Vector Academy [4] supplies the necessary basic knowledge related to ECU communication in the automobile in the framework of seminars on CAN, LIN, FlexRay and MOST. Literature and links: [1] www.diw.de [2] www.mostcooperation.com [3] www.vector-group.net/most/en [4] www.vector-academy.com Eugen Mayer (Graduate engineer; technical teaching certificate); after vocational training as a communication electronics technician, he studied electrical engineering and technical education at the Technical College of Ravensburg/Weingarten and the University of Stuttgart. Since 1999 he has been employed at Vector Informatik where he works as a Senior Trainer.
Figure 7: Background knowledge on optical signal transmission in a MOST system
1/92
1/93
C over Story FunCTIOnal S aFE T y
auThORS
DiPl.-ing. niCo aDler works as Research Scientist in the Embedded Systems and Sensors Engineering Department at the FZI Research Center for Information Technology in Karlsruhe (Germany).
Dr. eDuarD Metzker is Senior Product Management Engineer for Systems Engineering Tools at the Vector Informatik Gmbh in Stuttgart (Germany).
Dr. alexanDer ruDolPh works as Safety Manager in the Business unit Vehicle Dynamics Division at the Continental aG in Frankfurt/Main (Germany).
Derivation
With the publication of ISO 26262 “Road vehicles - Functional safety”, the automotive industry, its development processes, and resulting products are subject to explicit safety requirements for the first time. Manufacturers don’t just have to evaluate a portion of the system during the particular development phase but rather must evaluate the whole system throughout its life cycle. The hardware development is accompanied by extensive requirements and effort in the form of prescribed hardware safety evaluations and specific safety case documents. The following describes an efficient methodology that supports an iterative design/analysis process and has been integrated into the model-based PREEvision system engineering tool. In 06I2014
2/0
Volume 9
addition to presenting the methodology and tool support based on ISO 26262, a specific application is explained involving safety evaluations for a newly developed electronic braking system (EBS). FunCtional SaFet y in the harDware Context
The activities and work products demanded by ISO 26262 [1] are extensive and, despite the very well-structured and prepared standard, are often difficult to introduce into existing processes and tool chains [2]. The standard describes two different design phases for product development at the hardware level according to Part 5: The hardware architectural design consists of hardware components and describes an abstracted and functional view of a preliminary hardware design. The hardware detailed design, in contrast, is made up of hardware parts and represents a refinement of the hardware components at the level of electronic schematics. In the following, these will be referred to simply as hardware designs and hardware elements. Required safety evaluations regarding the analysis of random hardware failures are based on statistical failure information and are described in Part 5 Clause 8 for the “Evaluation of the hardware architectural metrics”. In turn, this evaluation is composed of the “singlepoint fault metric” and the “latent-fault metric” and enables conclusions to be drawn about the robustness of the hardware design. This evaluation is complemented by the “Evaluation of safety goal violations due to random hardware failures” described in Clause 9, which represents probabilistic safety analyses. Two different evaluations can be applied here: “Evaluation of Probabilistic Metric for random Hardware Failures (PMHF)”, which requires a global analysis of the design, and “Evaluation of each cause of safety goal violation”, frequently referred to as the FRC method, which represents an individual classification of single hardware elements. ProCeDure For harDware SaFet y evaluation
Model-based environments are particularly well-suited for supporting safety
11
2/1
C over Story FunCTIOnal S aFE T y
2 Excerpt of failure data table with results of the “Hardware Architectural Metrics” as well as the FRC method
1 Modeling of hardware design at different abstraction levels
evaluations required by ISO 26262 in iterative and collaborative development projects. Hardware designs based on specific libraries are modeled with deposited failure information. The model information enables the demanded safety evaluations to be carried out with the support of a database and thus with significantly less effort [3]. A continuously updated display of the calculated evaluation results supports the iterative approach for different development phases. This simplifies goal-oriented design changes. Automated report documents enable an overview of the development progress to be obtained at any time and decrease the documentation effort. Failure library
Statistical information regarding failures of hardware elements, such as failure rates, failure modes and failure rate distributions among failure modes, are administered in a failure library. The failure library is typically populated from recognised industry sources such as Siemens Norm SN 29500 and can be easily expanded to include
12
2/2
empirical knowledge from companyinternal databases. Failure information that has been added can be reused in different hardware designs by different development teams. integrateD MoDeling
At the beginning, safety goals with their associated automotive safety integrity level (ASIL) are derived from a hazard analysis and risk assessment (HARA) of the complete system and stored at the requirements level. A refinement is carried out using functional and technical safety requirements, which can be iteratively updated. It is also necessary to define safety mechanisms with specific values for the diagnostic coverage with respect to residual faults and latent faults. For modeling of the hardware design, the functional and technical safety concepts can be realised in the form of the hardware architectural design, 1 (a), and the hardware detailed design, a (b). The hardware elements including failure information which are deposited in the library can be dropped directly to the appropriate diagram a (c).
traCeabilit y anD DeSign oPtiMiSation
Because the failure information of the hardware elements is transferred from the failure library, consistent and traceable results are guaranteed, 2 (a). The engineer is relieved of having to maintain the data and can focus on the analysis and optimisation of the design in terms of its functional safety. Thus, the effects of newly introduced safety mechanisms or additional hardware elements on the evaluations can be analysed.
in combination with other independent failures is given. The failure modes can be classified in the context of the safety goal directly in the editor or automatically using a qualitative fault tree analysis (FTA). The “Evaluation of the hardware architectural metrics” is performed for one or more safety goals. For the “Evaluation of each cause of safety goal violation” at the level of the hardware element, a ranking into a failure rate class and a specific diagnostic coverage is considered. Target values are derived from the ASIL of the safety goals and their fulfillment is highlighted graphically, 2 (b). The evaluation of a PMHF is supported by a qualitative and quantitative fault tree analysis. For this, the calculation of a probability as a worst-case estimate for occurrence of the top-level event in the
fault tree, as the violation of the safety goal to be assessed, is provided. The determination of average probabilities (footnote: this corresponds numerically to the “Conditional failure intensity”, thus the probability of failure at time T on condition of freedom from failure at time T0. As worst-case, the system lifetime can be set as T-T0 = Lifetime.) from the failure rates is achieved using a customisable latency time T. Additionally, the qualitative analysis of the fault tree using minimal cut sets enables the definition of design constraints. rePortS
The effort associated with the documentation requirements of ISO 26262 is not trivial. The model-based approach offers significant benefits here as well.
For safety evidence, it is possible to generate review reports during the design phase as well as documents for argumentation of the “safety case” after finalisation of the hardware design. These can also be used for a possible certification of the hardware. Automated creation of the safety case documents is possible at any time during development. These documents give an indication of the current status of the hardware safety of the system. ebS aS an ex aMPle SCenario
This example involves the safety evaluation for a brake-by-wire (BBW) electronic braking system currently under development. For display purposes, the evaluation is limited to the redundant power supply of the EBS, 3. Among other
harDware SaFet y evaluationS
Several editors are available for the model-based application of safety evaluations. These can be used to provide a structured and prepared display of the evaluation results while offering different perspectives of the evaluations. The failure data table according to ISO 26262 contains the safety goals to be analysed, the safety-related classifications as well as the failure information annotated in the library. Information regarding a potential direct violation of the safety goal and a potential violation
3 Evaluation of the power supply system element from an electronic braking system 06I2014
Volume 9
13
2/3
C over Story FunCTIOnal S aFE T y
the evaluation results. This shortens the optimisation cycles drastically. Thanks to the collaboration support, distributed teams can jointly drive the design and analysis and implement changes faster and more reliably. The model-based combination of hardware safety evaluations with other work products of ISO 26262 is possible and desirable. This enables automated checks of work products for formal completeness and consistency as well as automated generation of reports, including the safety case. reFerenCeS [1] International Organization for Standardization, ISO 26262 Standard, Road vehicles – Functional safety (2011) [2] adler, n.; Otten, S.; Schwär, M.; Müller-Glaser, K.: Managing Functional Safety Processes for automotive E/E architectures in Integrated Model-Based Development Environments. In: SaE Int. J. Passeng. Cars – Electron. Electr. Syst. 7(1), pp. 103 – 114, doi:10.4271/2014-01-0208 (2014) [3] adler, n.; Otten, S.; Cuenot, P.; Müller-Glaser, K.: Performing Safety Evaluation on Detailed hardware level according to ISO 26262. In: SaE Int. J. Passeng. Cars – Electron. Electr. Syst. 6(1): pp. 102 - 113, doi:10.4271/2013-01-0182 (2013)
4 Fault tree and derived safety requirements as well as design constraints
things, the focus here is on the interfaces between requirements, architecture, design and their derivation with deductive safety analyses. The safety goal SAF_REQ_1 “The average probability of loss of BBW auxiliary energy shall be less than 3e-09/h” was derived from the HARA. The functional safety concept provides the power supply to the adjacent EBS-Actuator system element primarily via terminal KL30_2. In case of need, the ALT selector switch can be used to switch to the secondary power supply VP1. This is used as cold redundancy to increase availability and is switched on in emergency operation.
14
2/4
Application of the integrated concepts yielded the fault tree shown in Figure 4a. The top-level event occurs if “Undetected loss of VP2”, “Loss of VP2 and loss of cold standby (VP1 or ALT)” or “Loss of cold standby (VP1 or ALT) in emergency operation” occurs. Through the minimal cut set analysis, the budgets for the occurrence probabilities of the individual minimal cut sets were assigned and the safety requirements (functional and technical) and design constraints shown in 4 were derived. For multiple-point faults (cut set order greater one), the permissible budgets of the individual faults can be determined and the degradation and emergency operation characteristics
(maximum duration and warning concept) can be specified, 4 (c).
thanks
ConCluSion
All hardware safety evaluations demanded by ISO 26262 are fully supported in a single integrated solution. This eliminates additional work and error sources caused by inconsistent data sources, a change of tools and tool breaks. The library approach unburdens the engineers to carry out design and analysis and provides a high level of reusability. Effects of hardware design modifications or introduction of safety mechanisms are instantly observable in
Special thanks to Prof. Dr.-Ing. Klaus D. MüllerGlaser and Stefan Otten, who worked on this article too. Klaus D. Müller-Glaser is Head of the Institut für Technik und Informationsverarbeitung (ITIV) in Karlsruhe (Germany) and Stephan Otten works as a Research Scientist in the Embedded Systems and Sensors Engineering Department at FZI Research Center for Information Technology in Karlsruhe (Germany).
06I2014
Volume 9
15
2/5
Common to Architectures 1 + 2 150% Architecture 100% Architecture 2 100% Architecture 1
Common to Architectures 2 + 3 Common to Architectures 1 + 3 100% Architecture 3 Figure 1: Relationship of 150 % and 100 % Architectures
Common to all Architectures
From Feature-definition to Service-bay: Taking Advance Engineering Design Data beyond the ‘Systems-Vee’
Obviously not all combinations of features that could be
PREEvision provides a hierarchical table editor to facilitate
present in a Feature List are sensible in an implementation.
the documentation of Feature Lists; each item in the Feature
Therefore a critical step in the development of Architec-
List becomes a model artifact (or just ‘artifact’), and is able
tures is the detection of dependencies and exclusions that
to be used within the tool in a number of ways. Firstly,
exist between individual items in the 150 % Architecture.
PREEvision provides a rich-text editor to allow artifacts
Modelling the 150 % Architecture facilitates the determina-
within the Feature List to be documented – for example
tion of these dependencies and exclusions and enables the
with textual ‘user stories’, or with diagrams, photos, or
creation of a ‘Feature Model’.
scanned in concept sketches, as shown in Figure 2.
An ongoing trend within the automotive industry is that evermore complex systems are required to meet the demands of
Secondly, PREEvision then allows Feature List artifacts to
highly developed markets and stricter legislative environments. These systems have the potential to make vehicles both
Describing the Feature List as a Functional Architecture
be refined or specified to a more granular level through
more efficient and safer; however, the complex system interactions that they rely on may be difficult to diagnose when
Vector’s PREEvision tool provides a powerful environment
linking them with ‘traditional’ textual requirements created
faults occur.
for modelling Feature Lists, and their interrelations and re-
in a rich-text editor, as shown in Figure 3.
alisations (in both an abstracted logical form and in terms
Thirdly, PREEvision allows the realisation of a Feature List
of required hardware and software). Use of an inbuilt re-
artifact to be documented in terms of abstract require-
Conventional wisdom says that knowledge-based ser-
design process begins with the list of functions or features
solver in the tool then allows conflicts and dependencies in
ments for sources of information (‘Sense’), processing of
vice-bay systems are best suited to addressing issues that
that are required to be provided by the platform (hereafter
the Feature Model to be automatically found.
data or decision making (‘Logical Function’) and outputs
occur in the field within such complex systems. However,
referred to as the ‘Feature List’).
the period immediately following the launch of a new vehi-
Typically the Feature List is broken down by vehicle model
cle model is when service-bay systems that rely on a knowl-
or variant and is accompanied by a list of Requirements
edgebase are weakest due to a relative lack of accumulat-
that limit, refine and specify how each variant of each
ed information, and this is possibly the time that deep-dive
model will be delivered to meet market, corporate and leg-
knowledge is needed most to identify and resolve complex
islative needs. We can consider that each model-variant
issues that have ‘slipped through’ test and validation activ-
Feature List constitutes a set.
ities. Through reuse of advance engineering data Vector
The job of the systems architect is then to develop an overall
has identified a route that allows additional information to
architecture that is able to deliver the super-set of all indi-
be made available to field-support engineers and techni-
vidual model-variant sets while ensuring that any individual
cians during this critical time.
Feature List remains mutually consistent. One can think of
Advance Engineering Data
model-variant then being a ‘100% Architecture’ (see Figure 1).
During the early phases of a new vehicle program large
When taken alone the 150 % Architecture is generally not
quantities of data are generated in defining the architec-
able to be physically realised since attempting to do so
ture that will be employed, whether as a variant of a com-
would mean attempting to create a left-hand-right-hand-
mon platform or as a ‘standalone project’. The architecture
drive petrol-diesel-hybrid coupe-convertible-estate!
the super-set as being a ‘150 % Architecture’ with each
2/6
Figure 2: Rich-text definition of Feature List artifacts
2/7
From Feature-definition to Service-bay: Taking Advance Engineering Design Data beyond the ‘Systems-Vee’
Figure 5: Detailed logical modelling of vehicle speed calculation
Figure 3: Refinement of Feature List artifact by textual requirement
many projects while technical innovations might drive many
ly used in the vehicle, whether by conventional wiring or by
changes in the software and the hardware between indi-
communications buses (finer grained modelling, down to
vidual projects.
individual wire and harness pin is possible, but is not discussed in this paper). Such hardware could include Sensors,
models to be traversed in multiple directions by automated
Modelling the Implementation
Electronic Control Units (‘ECUs’), Fuse/Relay Boxes, and
provide vehicle speed to the driver could be modelled at a
queries.
Similar to the construction of the Logical Architecture it is
Actuators. Again, mappings are possible between the soft-
high-level as shown in Figure 4.
The number of logical block artifacts in a complex realisa-
possible to model the relationships between software
ware and the hardware block artifacts. It is possible to
It is then possible to create a more detailed model of the
tion may give rise to the need for many mappings to be
functions required in the implementation of the abstract
show the mappings of the software to the hardware in
content of the ‘vehicleSpeedLogic’ block, for example as shown
made, so to ease the mapping of Feature List elements to
logic as software artifacts, and mappings are able to be
‘call-outs’ in the diagram(s), as shown in Figure 6.
in Figure 5. A hierarchical description of the logic that will
their realisation PREEvision provides the concept of ‘Activi-
made between the logical and software blocks to show the
Both the Logical Architecture and the Software Architec-
be realised by the various subsystems of the vehicle is pos-
ty Chains’ – these allow the logical blocks relating to a spe-
relationships between them, in this way a 150 % ‘Software
ture may be annotated to show the data types that will
sible, with abstracted high-level blocks able to be used as
cific artifact in the Feature List to be grouped together in
Architecture’ is created.
apply to any ‘Data Element’ that will be transferred from
shorthand for the low-level detail in diagrams for other
another artifact, the Activity Chain, and then a single map-
Next, a 150 % ‘Hardware Topology’ may be created to de-
one artifact to another. This definition is able to be per-
feature realisations. It is therefore important to note that
ping created between the Feature List artifact and its re-
pict the interconnections between the hardware potential-
formed in-line with the requirements of AUTOSAR, and
while diagrams may be used to easily build the design in
spective Activity Chain to implicitly include all relevant logic
PREEvision, a diagram in a PREEvision design model only
(the Activity Chain is analogous to a Control Sequence de-
shows a small part of the ‘whole truth’ and may in fact de-
scription). The complete modelling of the mesh of logical
liberately abstract some of the truth away in the pursuit of
blocks required to realise all artifacts in the 150 % Feature
overall clarity.
List therefore makes up a 150 % ‘Logical Architecture’.
As is implied by the ‘Type’ labels shown in the blocks of
The use of Activity Chains also allows a judgement of where
Figure 5, PREEvision supports the use of user-defined part
areas of commonality and exclusivity exist between fea-
libraries. To improve modelling efficiency prototype arti-
tures and reuse of data sources and system outputs is fa-
facts can be created and included into the library ‘on-the-
cilitated. The Logical Architecture may be thought of as
fly’ – there is no need for a separate ‘block editor’.
representing prototypes of the artifacts in the software
Logical artifacts may be associated with specific parts of a
and the hardware that will be used in implementing the
Feature List by creating mappings in the tool between the
system. It should be noted though that a well-devised
artifacts. Such mappings are bidirectional and allow design
Logical Architecture might be stable over the duration of
from the system (‘Actuator’), for example, the feature to
Figure 4: High-level logical modelling
2/8
Figure 6: Hardware topology model, showing software mappings
2/9
From Feature-definition to Service-bay: Taking Advance Engineering Design Data beyond the ‘Systems-Vee’
once modelling of the Architecture is completed (including
Correctly routing the dataflow in a given 100 % Architec-
frames schedules according to the bus type(s) over which
Steps towards a Diagnostic Architecture
a Communications Structure, see below) an AUTOSAR
ture is a potential headache if following a manual process;
the signal must travel in the Architecture and thereby real-
As a first stage we are able to create a type of artifact
System Description file is able to be exported for consump-
however, PREEvision provides a signal routing mechanism
ise a ‘Communications Structure’ for the Architecture.
called a ‘malfunction’ and map these to the parts of the
tion in downstream product development activities.
that is able to automatically analyse the defined dataflow
With the Communications Structure in place then in addi-
Functional Architecture to match our high-level diagnostic
At this point the design model is sufficiently complete for
against the Hardware Topology to determine the best
tion to AUTOSAR-based export functionality, PREEvision
requirements (according to generic corporate requirements
that constraints to be added to it that specify any desired
routes, including, for communication bus (or sub-bus) sys-
also provides for export of LDF, DBC and FIBEX files for
or as the outcome of some detailed analysis). As an exam-
exclusion and inclusion relationships between artifacts (for
tems, the optimal points at which to locate inter-bus gate-
downstream, legacy processes that depend on such file-
ple, we will assume that the following ‘generic’ classes of
example, “Xenon Headlamps are mutually exclusive with
ways. It should be appreciated that this automated routing
types.
malfunctions exist according to some generic corporate re-
Tungsten Filament Headlamps”), and the content of each
algorithm ‘optimises away’ any signals within the Function-
desired variant model can be specified in terms of Feature
al Architecture that do not need to pass outside any given
Adding Information Relevant to Service
should be diagnosed accordingly (we will consider that log-
List artifacts, PREEvision’s automated resolver mechanism
hardware artifact, for example, if the source and sole con-
While the Functional Architecture and Communications
ical functions are only able to sustain systemic faults and
is then able to determine any incompatibilities in the Fea-
sumer of a Data Element are mapped to the same single
Structure are the basis of many further activities in the
ture Lists by traversing the mappings in the model to de-
ECU in the Functional Architecture there is no need for a
product development process, it may be appreciated that
that these should be ‘flushed out’ prior to series production): >>Sensors can have two types of malfunction:
termine the actual content of the desired 100% Architec-
signal to be created.
the relationships defined in the PREEvision model and de-
tures.
Following the signal routing activity, the path of any signal
scribed so far are useful once development of a given vehi-
may be visualised in the Architecture by simply selecting it,
cle has ceased and it has entered series production, and
Defining a Communications Structure
this then highlights the mapping locations of the source (in
eventually the service-bay. For example, all logical blocks
Once a model has been developed to the level described so
yellow) and consumers (in light brown) of the correspond-
that are part of (or feed into) an Activity Chain that depicts
far and any incompatibilities in the Feature Lists resolved
ing Data Element along with the path taken between them
the realisation of a given artifact in the Feature List may be
Malfunction mappings may then be created to link such
then we can think of the Logical Architecture and Software
and any gateways traversed (in orange), as shown in Figure 7.
found by traversing the model using an automated querying
malfunction artifacts with the artifacts in the Functional
Architecture in combination with the Hardware Topology
Once the dataflow in the Functional Architecture has been
mechanism that is built into PREEvision, and a query made
Architecture, as shown in Figure 8.
as constituting a ‘Functional Architecture’; where the Logical
routed PREEvision provides an integrated network design
in this way is therefore able to be used as a ‘first call’ source
By following the mappings in the Functional Architecture
or Software Architectures define a dataflow and the Hard-
environment to allow signals to be allocated to protocol
of data if a field support engineer is dealing with a fault in
between the Logical Architecture, Software Architecture
ware Topology defines potential routes for the dataflow.
data units (‘PDUs’), PDUs to be allocated to frames and
a new, complex system for which no knowledgebase exists.
and Hardware Topology we can then determine which pro-
Further to this, in the same way that we can annotate the
cessors should run diagnostic routines to detect these two
Logical and Software Architectures with definitions that
malfunction classes and we can then create corresponding
relate to their normal (functional) communication require-
Diagnostic Trouble Code (‘DTC’) requirements in the Archi-
ments we can annotate the Functional Architecture as a
tecture. PREEvision supports the concept of diagnostic
whole with definitions of diagnostic requirements.
master/slave relationships to enable the case where one
Figure 7: Hardware topology showing vehicle speed signal routing – see body text for key
2/10
quirements documentation for sensors and actuators and
– Electrical malfunction – e.g. disconnected – Signal/performance malfunction – e.g. out of range >>Actuators can have one type of malfunction: – Electrical malfunction – e.g. disconnected
Figure 8: Generic malfunctions mapped to logical sensors
2/11
From Feature-definition to Service-bay: Taking Advance Engineering Design Data beyond the ‘Systems-Vee’
model while taking into consideration any master/slave in-
Summary
teractions modelled in the Hardware Topology, so PREEvi-
The introduction of highly complex, interconnected systems
sion provides an interface to allow the export of diagnostic
into the automobile brings with it great opportunities to
requirements allocated to a given ECU for further detailing
help make vehicles meet ever more stringent safety re-
in Vector’s CANdelaStudio tool for consumption in down-
quirements from legislators while simultaneously delivering
stream processes.
‘surprise and delight’ functions and features to customers.
Next though we can use malfunction artifacts described
However, the complexity of such systems and their interac-
previously to also bidirectionally link the Logical Architecture
tions means that they can be potentially difficult to diag-
with the Diagnostic Architecture, as shown in Figure 10.
nose in the event of a fault occurring in service.
Further to this, the Malfunction artifacts may also be used
This very complexity though has also led to the develop-
in developing a functional safety concept analysis, and in
ment of systems design tools such as Vector’s PREEvision
such a case we can also consider that we have linked our
tool, and the design models that are developed in such
Functional Safety Concept, Functional Architecture and
tools have the capability to provide a powerful, new source
Diagnostic Architecture designs together.
of information to the hard-pressed service-bay environment based on the original design data for the vehicle.
Using Advance Engineering Information in the
The introduction of diagnostic modelling artifacts into
Service-bay
PREEvision has increased the potential usefulness of the
If we can assume that each DTC requirement that is creat-
information that can be mined from the design model as
ed in the Diagnostic Architecture is realised within the soft-
now not only the inputs to the logic delivering a feature or
ware released for vehicle production then we can now use
function may be found but also the DTCs that could impair
the links and mappings in the PREEvision design model
features or functions are able to be determined from a
(whether by automated query or by manually ‘walking
single source of information.
through’ them) from a Feature List artifact to find the inputs to the functions contained in its Activity Chain, as deFigure 9: Model structure for diagnostic artifacts
scribed before. However from the logical blocks we can then also find any DTCs associated with the system that
Iain Cunningham (BEng(hons), MSc) has been employed at Vector GB Ltd since 2013. He works in the Process Tools and Diagnostics areas, where he is responsible for business development activities.
could potentially lead to the function or feature being imECU or processor aggregates diagnostic information for
paired – this could be essential information for a dealer
one or more other ECUs, (smart) sensors or (smart) actua-
technician when in the service-bay while attempting to di-
tors, an example of how diagnostic content looks in the
agnose a fault in a complex, unfamiliar system.
structure of the model (including requirements Diagnostic
Of course, the highly connected nature of vehicle systems
Data Identifiers and Diagnostic Measurements and Diag-
and functions means that one particular fault in a vehicle
nostic Controls in addition to DTCs) is provided in Figure 9.
electrical system could lead to a number of features or
In creating such a structure we can consider that we have
functions being impaired, and since the links and mappings
started to create a Diagnostic Architecture that is linked
in the PREEvision design model are bidirectional we can
(bidirectionally) to the Functional Architecture via the
also consider the opposite use case, where if we find a DTC
Hardware topology. The main purpose of this modelling is
in a vehicle would can run a query against the design model
to facilitate the development of ECU-level diagnostic spec-
to find all the Feature List artifacts that might be impaired
ifications while following the requirements defined in the
by that DTC, again, very useful information in the service-bay.
Figure 10: Mappings between Logical and Diagnostic Architectures via a malfunction
2/12
2/13
parameters as well as mechanical and electromechanical
are only possible if the test bench seamlessly emulates the
stresses and in extreme situations. In temperature cycle
electrical and electronic vehicle environment. This means
durability tests, for example, the devices and PC-board as-
that signals must be generated with realistic voltages and
semblies are subjected to thermal shocks from -40 to
currents at all digital and analog inputs. This also applies to
+120 °C. Mechanical stresses can range from vibration tests
connected loads and to what is known as remaining bus
with sinusoidal oscillations and noise characteristics to in-
simulation. That is because, in addition to CAN, other bus
dividual mechanical shocks with accelerations as high as
systems – such as FlexRay, LIN and MOST – have become
30 g. Moreover, sealing tests are performed in tests with
well established in the automobile with numerous ECUs
salt spray fog, extremely fine sand and splash water, while
communicatinge simultaneously on multiple buses. These
high-pressure cleaning devices simulate engine washing.
multibus systems further increase complexity and must also be simulated properly in the remaining bus simulations –
Virtual ECU Environments
and sometimes the functionality of gateways must be sim-
A precondition for these tests is that the ECU must be elec-
ulated as well.
trically and functionally active. However, representative
Some time ago, the test bench engineers began their
tests and comprehensive diagnostics of ECU functionality
search for a more advanced and flexible test bench solution that could handle the growing complexity of ECU tests and available timeframes that would meet their future needs. The solution was to be implemented globally and uniformly at all ZF TRW business sites. Since then, the automotive supplier has started up a total of 32 of the new test benches in Germany, the USA, Czech Republic and China. Each test bench consists of a 19” cabinet with six rack-mounted units, so each stand can test six ECUs in parallel (Figure 1). Each cabinet has a scanner, a touchscreen and a keyboard for user inputs, display of results and readout of status mes-
Quickly Converting Test Benches Worldwide in Record Time
sages (Figure 2). The individual rack-mounted units are supplied with energy from a central power supply that can
Record-Breaking
supply electrical currents of up to 500 A for high-current for consumers and a nominal voltage of up to 30 V. These
The numerous tests that are required before an ECU is released for production represent a considerable share of the
high power levels are required for tests of the ESC control-
development costs for the ECU. In addition, the effort required for conceptualizing test benches and programming test
lers, in which 580-Watt drive units are responsible for
sequences has grown immensely in recent years. Of equal interest are the impressive cost and time savings that automo-
building up brake hydraulic pressure, and high ramp-up cur-
tive supplier ZF TRW is realizing in its new generation of test benches. For example, the company was able to reduce its
rents occur. Despite its high energy capabilities, it is neces-
test bench setup times from many months to just a few weeks by using component-based test benches.
Years ago, anti-lock braking systems (ABS) were consid-
Testing Effort Reached Pain Threshold
ered ambitious equipment for vehicles and were only of-
The products that automotive supplier ZF TRW develops at
fered beginning with upper mid-class vehicles. Today, com-
its Koblenz facility in Germany include controllers for ESC
plex extended traction control systems such as ESC (Elec-
systems. The growing complexity of its developments is re-
tronic Stability Control) are now state-of-the-art. The
flected not least of all in its increased testing effort. Both
evolution from ABS to ESC clearly illustrates how the com-
the numbers of ECUs and their extended functionality are
plexity of automotive electronics continues to grow in all
resulting in test cost increases. Over the past ten years, the
fields. In contrast to an ABS system, which is only active
number of ECUs installed in a premium vehicle has grown
when the driver brakes, an ESC system operates practical-
from around 30 to as many as 200. The technical effort
ly autonomously. Accordingly, more sensors are needed to
involved in the numerous test scenarios for testing every
provide the system with acceleration data and information
ECU type under all conceivable operating and environmen-
on transverse and longitudinal forces, torsional motion, etc.
tal conditions is tremendous. A special ECU version is re-
Therefore, newer ECUs must be able to process the data of
quired for each vehicle model and each OEM. At ZF TRW,
increasing numbers of signals from their own sensors and
one ECU variant is implemented as an ESC system and one
data from connected bus systems.
variant has an integrated parking brake as well. Each ECU must pass numerous electrical, functional and mechanical, environmental in addition to EMC tests before product release. Simulations must recreate environmental
3/0
Figure 1: Six rack-mounted units or subsystems, each of which represents a unit for testing one ECU. One test bench can test a total of six ECUs simultaneously.
Figure 2: User-friendly concept with touchscreen, scanner and keyboard simplifies operation of the test benches
3/1
Quickly Converting Test Benches Worldwide in Record Time
Figure 3: The modular VN8900 network interface with integrated real-time computer plays a central role in the ECU’s network communication.
parallel accesses to multiple bus channels, it offers high I/O
ZF TRW realizes from this are greater stability and durabil-
modules which may be combined in various configurations.
performance with extra-ordinarily short reaction and re-
ity in long-term tests. Previously, the PC would sometimes
The company can rapidly adapt the test bench concept to
sponse times and very minimal latencies. Along with vari-
crash after a couple of months in the long-term tests which
tests for other types of ECUs, e.g. for airbag controllers or
ably configurable bus interfaces, the system also offers
took up to six months to complete. This was annoying, be-
driver assistance systems. The drastically shortened change-
extension options for analog and digital inputs/outputs.
cause the computer could then no longer provide any mon-
over times and the speed with which managers can now
This intelligent interface is easy to configure from a PC over
itoring of the ongoing test process. Such problems have yet
respond to changes in requirements are very impressive.
USB or Ethernet.
to occur so far with the new test benches.
Future systems for autonomous driving are already en
Since the VN8900 systems was optimized for the use with
Today, a strict separation is made between test controlling,
visioned. When testing the radar and camera systems,
Vector CANoe and CANalyzer simulation and analysis
visualization and communication with the ECU. The
which are indispen-sible for these future systems, the new
tools, the new test benches can easily and seamlessly be
VN8900 system communicates with a Linux-based host
test bench concept will offer many opportunities for fur-
integrated into the tool chain at ZF TRW. This means that
computer from Smart Testsolutions via the LAN interface.
ther exploiting its capabilities and streamlining potential.
existing CANoe remaining bus simulations, which are avail-
In this case, a special real-time capable Ethernet/UDP pro-
able in the development departments, can be reused prac-
tocol supplied by Vector, which is known as FDX (Fast Data
Translation of a German publication in Elektronik automotive,
tically in tests with minimal modifications. These remaining
Exchange), is used. By working closely together with Vector,
issue 9-8/2015.
bus simulations are already verified internally, so that no
ZF TRW was able to modify the FDX protocol to meet its
additional effort is needed for quality assurance when they
own needs. In this framework, it implemented data ex-
Image rights:
are reused. This approach essentially eliminates all internal
change by the FIFO principle, for example. In turn, Vector
Figures 0–2: ZF TRW
concerns from the outset, and it leads to noticeable work-
got ideas from ZF TRW about ways to further develop the
Figures: 3–4 Vector Informatik GmbH
load relief for employees and especially for the project lead-
VN8900 system. FDX offers wide-ranging access to auto-
er. The approach reduced changeover times drastically: be-
matically running tests along with enabling starting and
Links:
sary to manage energy consumption during parallel tests
fore it could take up to eight months to retrofit an ECU test
stopping of applications. It also offers such capabilities as
Homepage ZF TRW: www.trw.com
to ensure that not all of the rack-mounted units demand
from OEM1 to OEM2, to a time period of just two to three
reading out and clearing error codes, reading and saving
Homepage Vector: www.vector.com
maximum power simultaneously.
weeks now. At the same time, there was a tremendous in-
XCP variables, influencing remaining bus simulations and
crease in flexibility in responding to late customer software
much more.
Focus on Intelligent Network Interface
changes shortly before the start of testing with modifica-
Using the VN8900, a special hardware device from Vector,
tion times of less than one week.
plays a central role in the solution used for the compo-
Budget-Friendly Solution For ZF TRW, extensive support of the necessary protocols
nent-based test bench (Figure 3). The ZF TRW test bench
Robust Test Sequences
was a key argument in favor of the Vector solution. Vector
supplier, the company Smart Testsolutions GmbH – not to
Another special aspect of the VN8900 system is the option
has specific solutions that support any of the commonly
be confused with the manufacturer of small cars – inte-
of automatic operation without requiring a connection to
used protocols and OEM-specific automotive networks
grates one VN8900 system per rack-mounted unit in its
an operating or monitoring PC. The test engineers use
and diagnostic systems on the market. When customers
solution (Figure 4). The VN8900 system is a modular net-
CANoe at a normal PC workstation to create the remain-
turn to lower cost hardware components from other man-
work interface for FlexRay, CAN (FD), LIN, J1708 and K-Line
ing bus simulations and test sequences in the CAPL script
ufacturers, they often experience higher subsequent costs
bus systems that is equipped with a dedicated x86 real-time
language. They can then be simply loaded into the VN8900
that offset any hardware savings when protocols need to
computer. Specially designed for applications with many
system and executed there. Some of the benefits that
be redeveloped for individual buses or for the XCP support
Stefan Siefert-Gäde, ZF TRW studied electrical engineering at the Technical College of Koblenz. In 2006, he began work at TRW Automotive in Koblenz. Since 2014 he has been coordinator for the global, strategic development of test equipment in the Global Electronics area.
Katja Hahmann, Vector studied Electrical Engineering at the Technical University of Chemnitz. In 1997, she joined Vector Informatik GmbH in Stuttgart, where she is now group leader for CANoe application development in the Networks and Distributed Systems product line.
for various OEMs that is often lacking. Vector also advantageously resolved a licensing issue for customers, because users like ZF TRW essentially do not incur any additional costs for updates by using what is known as the CANoe stand-alone extended license. Any number of test bench applications can be created using just one CANoe license on a development PC. Updates of the VN8900 systems to newer CANoe stand-alone extended versions are always included. Even towards the end of the life cycle of the new test benches, the customer can continue to use the VN8900 devices meaningfully at the workplace instead of having them become unused dead capital. Development Continues Figure 4: Block circuit diagram of a stand-alone subsystem; six of these units are installed per test bench.
3/2
With its new test benches, which were first used to test ESC controllers, the automotive supplier ZF TRW has a component-based test system that consists of six to seven
3/3
Tools
Tools
Tips and tricks for the use of CAPL CAPL is a programming language available in the software tools CANoe and CANalyzer. In three consecutive articles, CAPL fundamentals will be discussed as well as tips for all levels of user knowledge. Authors
Marc Lobmeyer
Roman Marktl Vector Informatik GmbH Ingersheimer Str. 24 DE-70499 Stuttgart Tel.: +49-711-80670-0 Fax: +49-711-80670-111 Links www.vector.com
T
his first part focuses on the basics of CAPL. It is primarily intended for those who are new to this language; however, it also offers a few insights for well-informed users into the motivation behind individual CAPL constructs. The second part will discuss advanced functionalities of CAPL. Finally, the third part will address performance and memory needs and offers tips and tricks on using databases and associative arrays. For over 20 years – it was initially used in CANalyzer for DOS – CAPL has been used to implement a broad bandwidth of tasks: from simple stimuli to the simulation of complex bus nodes. In the following, CANoe is illustratively named for the two products CANoe and CANalyzer. The goal of CAPL has always been to solve specific tasks as simply as possible. Typical tasks are reacting to received messages, checking and setting signal values and sending messages. A program should restrict itself to precisely these things and not require any additional overhead. Many programming tasks that CANoe users typically perform might actually be as brief and trivial as the example presented below – of course many other tasks are not so trivial. That is why CAPL has been continually extended over the years to be a tool that can also solve complex tasks according to the principle “as simple as possible”. “CAPL” is an acronym for Communication Access Programming Language. The
original focus on CAN has long been extended to all automotive bus systems such as LIN, Flexray, Most, J1587, as well as a few others like Arinc and CANopen. As in many other languages, the syntax of CAPL is closely based on the syntax of the C language. Those who are familiar with C, C#, or various modern script languages will quickly be quite comfortable using CAPL. However, a few unique aspects distinguish a CAPL program from a C program: CAPL programs are event-driven. This means that they consist of individual functions, each of which reacts to an event within the system under analysis: receipt of a message, change of a signal, expiration of a timer, or even a change in the environment. To react to the message “EngineState”, for example, you would use: “On message EngineState” (Figure 1). CAPL programs use specific databases for the concepts of the system under analysis. Messages and signals get their names there,
Example: a simple CAPL program In Figure 1 a simple CAPL program is presented, which
CAPL CAPL is a procedural programming language similar to C, which was developed by Vector Informatik. The execution of program blocks is controlled by events. CAPL programs are developed and compiled in a dedicated browser. This makes it possible to access all of the objects contained in the database (messages, signals, environment variables) as well as system variables. In addition, CAPL provides many predefined functions that support working with the CANoe and CANalyzer development, testing and simulation tools.
CAN Newsletter 2/2014 3/4
and these names can be used directly in the program code. In Figure 1, they are the names “EngineState” for a message and “EngineSpeed” for a signal in this message. CAPL programs do not give the user any pointer types to use. Right from the outset this excludes numerous potential programming errors and causes of program crashes, such as those that frequently happen in C programming. Nonetheless, since pointers − aside from their susceptibility to errors − also represent a very powerful concept, CAPL provides a substitute for some things, e.g. associative arrays as a substitute for dynamic memory.
One important property that CAPL shares with C should be mentioned: CAPL is always compiled, i.e. it is converted to efficiently executable and flexible machine code.
Figure 1: A simple example of a CAPL program performs one of the basic tasks of a bus monitoring tool: it listens to traffic on the bus and prepares a couple of events on the bus for observation/monitoring by the user. This is a shortened, sample CANoe program: “Display.can” from the sample “Easy.cfg”. In the following, first the overall functionality is briefly summarized, and then the individual sections are described in more detail.
signals it contains are conditioned for display on a panel, and they are routed to the panel for graphic display.
Intelligent Data Logging Description of
Lines 7 to 9 show a has been just transmitminimal form of a message ted. Only received messagevent procedure. This func- es should be considered in tion is called whenever this this program (value RX), beIntelligente Datenlogger sent by the message has been transmit- cause a message ted on the bus. In reference node itself would also trigto CAN, this means that the ger an event procedure (valprecise time point is the TX or ue TX). In this case, an error RX interrupt of the CAN con- message would be output in troller, i.e. immediately after line 15. Since conditioning of the correct transmission of the message. The message that signal for display on the user triggers the call of the partic- interface (a panel on which ular function is referenced by different states are shown by different bitmaps) is some“this” syntax. In line 8, the value of the what more complex, its im“EngineSpeed” signal is read plementation is outsourced to out from the received mes- a separate function: In line 13, sage (“this”) and is assigned “SetLightDsp” is called with to a system variable with a the two message signals that are needed as parameters. conversion (/1000.0). Finally, lines 19 to Lines 11 to 17 show a message event procedure 28 define a separate function, for the “LightState” message, which writes different values which transmits the informa- to the system variable “Lighttion for a turn signal flasher. Its Display” in the “Lights” name processing is similar to that of space according to the value the “EngineState” message of the transmitted signal. In with the following unique as- this demo configuration, this Essential sporadic then failures: selects the appects: In line 12,for the tracing direc- variable bitmap on of a display tion flag (.dir) is now checked • Selective recordingpropriate and analysis all in the message (“this”) that panel.
the program – From the compact to High-End he line numbers are not the flexible solutions for T
part of automotive the CAPL program industry
Task description The task is to observe a CAN network whose elements – e.g. bus nodes, messages and transported signals – are described in a database. When the “EngineState” message is received, then the Engine-Speed signal it contains is conditioned for display on a display panel, and it is routed to the panel. When the “LightState” message is received, the “HeadLight” and “FlashLight”
GL1000
and are only inserted here to make it easier to reference individual lines or sections. To achieve the most compact representation possible, opening brackets were not placed on a separate line. I
n a CAPL program, it is possible to define global variables and constants. This is done in the “variables” section (lines 1 to 5). These constants and variables are globally defined for this program: they can be used anywhere in the program, but not in other programs within the same CANoe application. The other sections define reactions to events (lines 7 to 17) and an auxiliary function (lines 19 to 28).
GL2000
GL4000
GL3000
common bus systems CAN, LIN, MOST150, FlexRay, Ethernet CAN Newsletter 2/2014 • Diagnostics, CCP/ XCP and customer protocols
3/5
Vector Informatik GmbH Ingersheimer Str. 24 DE-70499 Stuttgart Tel.: +49-711-80670-0 Fax: +49-711-80670-111 Link www.vector.com
CAN Newsletter (print) Tips and tricks for the use of CAPL (part 1)
There is a separate set of predefined macros for the conditional compiling of code sections.
Safety Basic Monitor with switchable AS-i Master - the new cost brake for 3 safe signals or more
#if (TOOL_MAJOR_VERSION == 7 && TOOL_MINOR_VERSION == 5 && TOOL_SERVICE_PACK < 2) || CANALYZER #pragma message("This program needs at least CANoe 7.5 SP 3") #endif #pragma message: The #pragma message directive lets users output their own message during the compiling process, e.g. the version number of the currently compiling CAPL program. It appears together with the other messages, warnings, errors, and general messages of the compiler.
Safe Link over Ethernet
Safety Technology by Bihl+Wiedemann › Safe Link over Ethernet: The simplest way of coupling many safe signals the
new standard
+
me
› Universally expandable with Safety I/O Modules + Standard I/O Modules in IP20 or IP67, Speed Monitors for up to 40 axis, Safety Relay Output Modules
et
ducts already
› Optimal PLC connection via fieldbus, all diagnostic data in the controller, safety and standard signals mixed
p ro
The preprocessor is a powerful tool in the C language,
write("The node name" " is %NODE_NAME%"); @Ch%CHANNEL% = 1;
They are #if, #else, #elif or #endif. Within a program, they allow distinguishing between the program types simulation node, measurement node and test program as well as the CANoe version that is used. Here is an example that uses a #pragma message:
All
Efficient programming in CAPL
No longer miss a bus with our Safety Gateways
me
Roman Marktl
A key difference between CAPL and C or C++ relates to when and how program elements are called. In C, for example, all processing sequences begin with the central start function main(). In CAPL, on the other hand, a program contains an entire assortment of procedures of equal standing, each of which reacts to external events: ◆ Triggered by the system: These events include those that are useful for initializing and post-processing the measurement run: on preStart, on start, on preStop and on stopMeasurement, as well as the time control and keyboard events on timer and on key. ◆ Triggered by bus communication: There are many different types of event procedures that react to bus events such as those related to communication or error handling, and they are very dependent on the bus type. Examples of these are on message and on busOff in CAN and on frFrame and on frStartCycle in FlexRay. ◆ Triggered by access to a Value Object: Such objects include system and environment variables that are globally available
ducts already
Marc Lobmeyer
within the current procedure always returns the old value even if the variable appears to be set to a new value within the same procedure. The advantage is that only one value change occurs at a single point in time. The execution model is situation dependent: There are many ways to use CAPL in CANoe and CANalyzer, and so the execution model varies somewhat, too: The simulation nodes of a CANoe simulation are in parallel on the bus. Hence, they are completely independent from each other. Triggered events are always dispatched to all programs. In contrast, nodes in the measurement setup and in CANalyzer are processed in sequential order: Each node passes its output to the next. Incoming events must be passed to the next node explicitly for further processing. The procedures on * and on [*] are provided for this purpose. Another type of program is a test program whose test procedures can wait for external events. CAPL resumes execution with the simulation time of such events. In contrast, waiting in normal event procedures stalls the entire simulation system. This is a frequent source of errors when CAPL is used. It is therefore inadvisable to use a busy-wait or wait command in an external DLL.
pro
Tools
Execution model
in CANoe and CANalyzer as well as signal values that represent a data interpretation of the bus communication. Special databases perform the interpretation. Part 3 of this series will address this concept. Event procedures are atomic: The simulation model of CANoe is event oriented. In event procedures, CANoe executes all actions simultane ously from the model perspective, namely at the point of in time of the triggering event. The actual computation time on a real PC is ignored. Simulation time and time stamp: However, a real event generated by the PC, such as a bus output by output(), gets a time stamp of the real-time clock. The sequence and time points of these events can be influenced by bus protocols, driver, and hardware properties. On a simulated bus, some of the mentioned influencing parameters are eliminated. In this case, bus events are initiated simultaneously; in the case of CAN, for example, this leads to a dependable arbitration of multiple messages that are output by output(). Updating system variables: Users can also use CAPL to modify environment or system variables that are visible outside of the program. CAPL does not propagate value changes to a variable until after the current event processing is finished, but with the same time of the just handled event. A read access
All
he second part also offers tips for all types of users so that they can work more effectively with CAPL in the areas of "generic programming" and "conditional compiling."
+
T
n ew s t a n d a r d
Authors
may be used freely within string constants, identifiers for variables, and function names. They always begin and end with a % character, and they are primarily used to write generic programs. Available code macros include the node name, index of the current channel, name of the current network and the type of bus being used. The code can access the name of the containing file with %FILE_NAME%, or it can access the name of the program file currently being compiled with %BASE_FILE_NAME%. In the case of Include files, the latter is the parent file. Here are two simple examples:
the
The first part of this series of articles addressed fundamental concepts of the CAPL programming language. This second part explains the time behavior of event procedures.
stopMeasurement may coexist in both the included file and the parent file. In these functions, the code is executed sequentially: first the code from the included file and then the code from the parent file. This means that the Include files are used to perform three tasks: declare data types, define variables and provide an (inline) function library. #pragma library: CAPL programs can use Windows DLLs created in other languages, as long as they implement a suitable CAPL DLL interface. These DLLs can be directly linked with the directive #pragma library("capldll.dll"). Macros: In CAPL, there are a number of predefined macros that are available to users for use in the code or for conditional compiling. Macros for use in the code can be used anywhere in the code without restriction. In contrast to C, macros
et
Tips and tricks for the use of CAPL (part 2)
but it can also lead to confusion and consequently to errors. Therefore, only a subset of the well-known preprocessor directives in C is offered in CAPL with comparable semantics. #include: Include files contain arbitrary but complete sections of a CAPL program: includes, variables and procedures. In contrast to C, the text of an include file is not simply inserted into the CAPL file, rather the sections. All sections of the included file apply to the entire parent CAPL file "as if" they were contained in that file. The sequence of sections is irrelevant in CAPL anyways. This means the compiler reports any duplicate symbols as an error. Moreover, code and data from included and parent files may use each other mutually. One exception to the just stated prohibition of duplicate symbols is that on start, on preStart, on preStop and on
More information on your application safety at:
CAN Newsletter 3/2014 3/6
www.bihl-wiedemann.com 3/7
The third and final part of this series presents tips and tricks for advanced users. Topics include associative arrays, performance, memory needs, and other database access options. Authors
Marc Lobmeyer
Roman Marktl Vector Informatik GmbH Ingersheimer Str. 24 DE-70499 Stuttgart Tel.: +49-711-80670-0 Fax: +49-711-80670-111 Link www.vector.com
CAN Newsletter (print) Tips and tricks for the use of CAPL (part 1)
Tips and tricks for the use of CAPL (part 2)
U
nlike languages such as C, CAPL does not support any pointer objects as a reference data type and therefore has no dynamic memory management. This makes CAPL very robust, and therefore well-suited for runtime environments that are short on memory and difficult to debug. In particular, CANoe's "CAPL-onBoard" feature benefits from this; in order to improve real-time behavior, it executes programs directly on certain hardware bus interfaces. Having said that, memory is seldom in short supply in the Windows’ runtime environment. Therefore in this runtime environment CAPL offers associative arrays that can be used to store data even if the amount of data to be stored is unknown at the program start. Associative arrays are containers which are equivalent to maps or dynamic arrays of other programming languages. Internally, CAPL uses an efficient hash table for these arrays. Consequently, these special arrays enable saving bus messages or measurement values, even if it is unknown in advance which messages or how many measurement values will occur. In CAPL, associative arrays are declared as simple arrays, but with a key type instead of the otherwise usual size entry. Two examples of associative arrays: long lastTime [long]; char[30] translate[ char[] ];
The variable lastTime is an array that maps long keys to long values, while translate
maps string keys (without length limitation!) to string values up to 30 characters. The following example uses lastTime to store a time value for each message ID occurring on the CAN network: on message CAN1.*{ lastTime [this.id] = this.time; }
To enhance the user’s experience, CAPL provides the following list of methods for associative array variables using dot notation: ◆ ContainsKey queries whether a specific key is already contained; ◆ Size returns the number of contained keys; ◆ Remove removes one key from the associative array; ◆ Clear fully empties an associative array. In fact, Remove and Clear free up memory. Finally, there is a special form of the for instruction for associative arrays. This form iterates over all keys actually contained in lastTime: for (long key: lastTime) {[…]} …
Access to databases Part 1 of this article series already illustrated the primary use of bus-specific databases in CAPL: they make it possible to introduce names for messages and signals. From a programming perspective, the complicated aspect of signals is that they are usually tightly packed in the data payload of messages for efficiency reasons. Therefore,
CAN Newsletter 4/2014 3/8
signals generally exhibit arbitrary bit lengths and positions within the data payload of a message. They can also be stored in either Intel or Motorola format. Symbol-based access via a signal name relieves the CAPL user of all of these details. In the case of reading or setting a signal value, the CAPL compiler automatically accounts for the signal’s precise bit pattern that may include masking, swapping and shifting the bits. To enhance user friendliness, other definable objects in the database may improve the linguistics of CAPL programming. For example, symbolic value tables may be associated with signals to use plain text names for signal value states. Furthermore, authors of a database have the freedom to define other attribute objects and to use them in the program code. CAPL is able to use database objects directly based on their symbolic names. However, sometimes the potential objects of interest are not known at the time of program implementation. Therefore, the CAPL user may dynamically access the symbolic names and properties such as message names and identifiers transmitted by a network node. A brief example: message * m; int i, mx; mx=elcount(aNet::aNode.Tx); for (i = 0; i < mx; ++i) { m.id=aNet::aNode.TX[i]; write(DBLookup(m).Name); }
Tools
Tools
Tips and tricks for the use of CAPL (part 3)
These symbolic access methods allow the user to implement generic programs – together with the previously introduced associative arrays.
Performance Most CAPL programs must meet non-trivial real-time conditions. The execution model of a node simulated with CAPL even follows the model concept that CAPL programs can be executed at any speed (see part 2 of this series of articles). To adequately approach this ideal, CAPL programs are compiled, i.e. they are compiled into the machine language of the specific executing microprocessor. Moreover, optimized code sequences are used for the often complex access to signals. Below are a few tips on how the user can affect performance. writeEx(): the write function is used to output specific texts to the Write window in CANoe and CANalyzer. As an alternative, the writeEx function is available for outputting larger quantities of data. For one, it can be used to write directly to the Trace window or to a log file. The text output generated by writeEx is in all respects treated like a bus event, including the high priority processing and synchronizing the time stamps with real bus events. Event procedures: a CAPL program consists of a combination of procedures
that react to events. Some of these events may occur very frequently. Therefore, a program's performance is significantly better if only those events get processed, which are concerned. For example, if the user is only interested in those Flexray slots that contain a specific signal, it is more efficient to define on frSlot signalname than on frSlot *. Signal edges: there are two event procedure versions for signals and system variables. on signal_update and on sysvar_update are called with each write access to the specific data objects, even if the object’s value has not changed at all. By contrast, on signal_change (on signal in short) and on sysvar_ change (on sysvar in short) offer a performance advantage if only signal edges are to be handled. Those event procedures are optimized to trigger on value changes only.
Memory needs Unlike most block-oriented languages, such as C, all locally defined variables in CAPL are static by default. This means that they are all created at the program start, and memory used to store these variables is not freed until the end of the program. Consequently, CAPL may require a surprisingly large amount of memory if many event procedures define the same type of large vari-
CAPL CAPL is a procedural programming language similar to C, which was developed by Vector Informatik. The execution of program blocks is controlled by events. CAPL programs are developed and compiled in a dedicated browser. This makes it possible to access all of the objects contained in the database (messages, signals, environment variables) as well as system variables. In addition, CAPL provides many predefined functions that support working with the CANoe and CANalyzer development, testing and simulation tools.
ables, which they could actually share. An example: testcase test789() { char outBuffer[1024]; [..]
There are CAPL programs with thousands of such test procedures, of which only one may be executed at any given time. Rather than defining a large local variable of the same type in each event procedure, defining the large variable once globally in the Variables section utilizes a lot less memory. Another inadvisable practice is to create very large arrays, e.g. to store event data under the respective message IDs. An extended ID in CAN comprises 29 bits, so it can assume over 500 million values. To define an array for this purpose would be a waste of memory. In such cases, it is better to use associative arrays as described above. Although associative arrays need somewhat more memory for each key that is actually used, they do not need any memory for keys that are not used.
Useful, relatively unknown features
CAPL programs should also not crash in case of faulty usage. On one hand, this robustness is attained by the language structure, since there are no general pointers. On the other hand, stability is improved by automatic runtime checks of array limits, stack limits and the necessary computing time. A separate commandline version of the compiler is available. This version is very helpful in automating sequences in script languages.
Concluding Remarks This series of articles has introduced CAPL as an example of a problem-oriented programming language. The familiar C language syntax of CAPL simplifies the user’s learning curve. Specific symbolic databases and concepts for using CAPL in simulation, emulation, and testing of fieldbus nodes support the application domains. Vector is carefully and continually extending the language in a way that maintains compatibility with previous versions while cultivating new application areas.
CAPL offers a number of less familiar and mainly newer features: Structs can be used to define structures, similar to the approach in C. Together with copying operations, which can also convert Intel and Motorola formats within a struct, they represent a flexible method for data conversion. When CAPL functions are called, the user has the option of passing reference parameters in addition to value parameters. Reference parameters make it possible to return more than one result value from a function. Reference parameters can also be used within CAPL–DLLs.
CAN Newsletter 4/2014 3/9
interaction layer converts the signal-based access of higher applications to the message-based transmission method of the bus system. Another important aspect is support of different types of network management (NM) such as OSEK-NM or the bus-specific AUTOSAR-NM. Stimulation by Control Panels and Run Sequences Applications on the upper OSI layer include signal panels and signal generators, for example. They are indispensible aids in simulating user activities and dynamic processes. They contain virtual switches, buttons and display instruments that can be used to conveniently input spontaneous operating actions on the computer screen such as activation of a turn signal, windshield wiper or window lift. They also show user system parameters and enable specific modification of signals and variables during the test runs. Therefore, a state-of-the-art test environment offers a suitable panel editor as a standard feature to create cusFigure 1: Remaining bus simulation enables testing of simulated nodes in a network with real nodes.
tomized panels with user control and to display instruments or standard panels (Figure 2), which are configured from database information. In automatically generating simulations and panels or in making signal assignments
Quick Paths to a Comprehensive Remaining Bus Simulation Create Virtual Networks without Programming Expertise A key task in developing ECUs is to create the remaining bus simulation. It ensures that a functional environment is available to the ECU, without which comprehensive tests could hardly be realized. The challenge for developers is to quickly generate a realistic remaining bus simulation that considers relevant constraints. With the right tools, it is possible to create remaining bus simulations without programming – essentially by drag & drop operations (Figure 1).
smoothly, the following is true: The more detailed the rele-
these databases, developers today are able to create re-
vant networks, messages and attributes are described in
maining bus simulations in just a few configuration steps or
the associated database, the more precise are the models
even generate them automatically. Programming know-
created by the generators. Preconfigured panels benefit
how is no longer an absolute necessity. Project participants
from all available information, such as signal descriptions,
simply add communication databases to the simulation
specified value ranges or symbolic identifiers.
setup by drag and drop operation. After this is done, the
Panels do indeed permit spontaneous and flexible manipu-
detailed behavior of individual network nodes can be mod-
lation of signals, but they are not capable of executing test
ified. Multiple bus systems may be assigned to a network
sequences, user inputs and other events reproducibly. This
node, which is important when comes to simulating gate-
is the domain of classic programming. Nonetheless, users
ways and more challenging ECUs.
often do not want to have to utilize powerful programming
In remaining bus simulation, key roles are played by consid-
tools for every project. Therefore, a welcome alternative for
eration of OEM-specific metadata and send models. The
test engineers is the option of creating test sequences in
The goals of a remaining bus simulation range from simu-
documentation. An example of this is the CANoe simula-
interaction layer comes into play here, since it represents
the form of a table (Figure 3). This table simply consists of
lating individual network nodes to simulating entire net-
tion and test system from Vector.
the defined sending behavior for the relevant OEM. The
commands to be selected, which perfectly fulfill their tasks
interaction layer correctly represents protection mecha
in many different test applications. They are used to set
works. From a technical perspective, the goal is to simulate
3/10
With the help of a suitable configuration assistant and
an ECU‘s infrastructure over all layers of the OSI model.
Configuring instead of Programming
nisms – such as a message counter and CRC computations –
values, define wait times, modify signals and trigger events.
This requires modeling from the communication layer to
Modern test and simulation systems should support differ-
for each message type according to the send model. The
This approach does not require any special knowledge, nor
the network management layer, transport layer and finally
ent types of generation (automatic, manual, programmed)
does it require great training effort, and it quickly leads to
the application layer. The aspects and task areas to be
for the remaining bus as well as differing complexities of
the desired results with small reproducible tests.
considered in the implementation are just as varied. They
individual tests. For example, it makes a large difference
might include selecting suitable hardware for the CAN, LIN,
whether a developer needs a small simulation for testing
A Precise Fit for Challenging Tests and Simulations
FlexRay and MOST bus interfaces and simulating ECU
just one or a few system functions, or whether comprehen-
Even large test scenarios no longer need to be programmed
functionalities via MATLAB/Simulink models on the upper
sive and detailed full tests are needed in the final phase of
by a classic approach today, if a simulation and test system
levels. The simulated remaining bus must receive messages
a product development. The primary source of data for re-
offers power-ful support for them. In standard cases, for
from the system under test, dynamically react to them and
maining bus simulations is the communication data of the
example, there are prepared test patterns that offer sup-
send results in the form of messages back to the ECU
various bus systems that is stored in DBC (CAN), LDF (LIN)
port for all steps: from setting up the stimulation and eval-
(stimulation). In the final analysis, the remaining bus simu-
or FIBEX (FlexRay) databases or in function catalogs
uation functions to results analysis, HTML documentation
lation is simply a means to an end. It is always embedded in
(MOST). Diagnostic descriptions such as CDD and ODX are
a high-performance development and test system, which
also incorporated. It is also possible to source all data from
evaluates the obtained test results and prepares them for
a single database such as the AUTOSAR system description.
Figure 2: Standard panels let users interactively modify signal values.
and preparation of graphic output. Details of interest can be shown in graphic evaluation windows. For example, color highlighting in CANoe’s State Tracker lets users quickly
3/11
Quick Paths to a Comprehensive Remaining Bus Simulation
Remaining Bus Simulation with CANoe
Translation of a German publication in Automobil Elektronik,
A comprehensive test and simulation tool, such as CANoe
issue 3/2012
from Vector, masters all aspects of the remaining bus simulation for test setups ranging from simple to comprehen-
Image rights:
sive. In particular, it lets users create the necessary simula-
Vector Informatik GmbH
tion models rapidly, either manually or automatically, in just a few configuration steps and without the need for pro-
Links:
gramming. The tool should be able to process all commonly
Home page Vector: www.vector.com
used data formats, diagnostic descriptions and metadata
Product Information CANoe: www.vector.com/canoe
and support the automotive industry with numerous OEM-specific packages. Numerous options for accessing messages, signals and symbolic identifiers simplify the work of ECU developers. Stimulation or flow control can be
Stefan Albrecht has been employed at Vector Informatik since 2003 and is currently working as a product manager in the central product management area for CANoe/CANalyzer.
implemented by using signal panels, the Visual Sequencer Figure 3: Graphic creation of command sequences for stimulation and testing with the Visual Sequencer does not require any programming knowledge.
(Figure 3), higher-level programming languages via the .NET API or the signal-based CAPL language. For complex test setups, the integrated Test Feature Set provides prepared test patterns for stimulation, evaluation, results analysis and HTML documentation. High-level features,
detect states, events and state changes (Figure 4). This
such as integration of MATLAB/Simulink models or ex-
type of representation is realized by an Art Logic Analyzer
pandability with supplemental hardware that simulates
for automotive networks or ECUs.
connected sensors and actuators, enable functionality that
As already suggested, there are hardly any upper limits to
extends to the area of mid-size HiLs (Hardware-in-the-
the conceivable complexity that can be handled in a remain-
Loop).
Peter Decker has been employed at Vector Informatik since 2002 and is currently working as a product manager in the multibus development area for CANoe/CANalyzer.
ing bus simulation. To fulfill the many different requirements individually, a test and simulation system should
Outlook: Remaining Bus Simulation and Electric Mobility
exhibit such properties as scalability and modularity. In ad-
In the future, the theme of remaining bus simulation will
dition to broad support of bus interfaces, intelligent hard-
also gain in significance in the area of electric mobility.
ware interfaces – e.g. those with their own computing
Fueled by the dynamic development in this area in recent
power – are increasingly gaining in importance, because of
years, efforts here are focused on network management
growing real-time requirements. They are capable of exe-
with simulation of partial network operation. That is be-
cuting time-critical processes. Another challenge is to gen-
cause parking periods for electric vehicles are of course
erate specific errors in the form of invalid messages, cor-
simultaneously charging phases, in which certain ECUs
rupt useful data or disturbances to the bus physics, with
need to be reliably switched off, while other components
the goal of studying ECU reactions to such situations. A
should remain active for charging and monitoring. The fact
modern test and simulation tool offers these capabilities
that the topic of partial network operation was a priority in
via special stress functions implemented in software and
AUTOSAR 4.0 compared to AUTOSAR 3.2.1 underscores the
hardware.
current importance of electric mobility.
Figure 4: The State Tracker graphically depicts system states and discrete values over a time axis.
3/12
3/13
the additional option of integrating real hardware. Here too, the simulation is started in Simulink. Unlike Offline mode, the time from CANoe serves as the basis for the simulation time here, and the simulation is computed in real time. One limitation worth mentioning is that the model may not be so complex that it is not possible to quickly compute it as real time. That is because adapting the “Simulink time” to “CANoe time” slows execution speed in Simulink and conforms it to CANoe’s real time base. However, this slowing cannot be performed any longer if model computation requires too much effort. If the model does satisfy the condition mentioned above, full access to real hardware is assured in this operating mode. The debugging capabilities of Simulink can also be used. However, synchronization of the simulation time is lost whenever model exeFigure 1: CANoe remaining bus simulation with simulated nodes
cution is paused. Online Mode or Hardware-in-the-Loop Mode
Model-Based Development of ECUs Software Simulation with MATLAB/Simulink and CANoe MATLAB/Simulink is a tool that is widely used in many engineering and scientific disciplines. In the automotive field, for example, it is used to model dynamic systems such as control systems, and to describe states and their transitions. Since these algorithms run on ECUs that communicate with one another, it is vital to provide access to the vehicle network over the course of the development process.
3/14
plicitly created by the user or automatically generated.
Model computation is executed entirely in the CANoe en
Automatic generation could be implemented by linking digi-
vironment here. This involves generating a DLL from the
tal/analog hardware to CANoe. Here, each port of the D/A
Simulink model, which can be loaded and executed in
hardware is mapped to a dedicated system variable. This
CANoe. The Real-Time Workshop of MATLAB/Simulink
lets the model interact directly with the connected D/A
controls code generation here. To generate code for CANoe,
hardware. After installing the CANoe MATLAB integration
a special “Target makefile” was developed for the Real-Time
package from Vector, a Simulink Blockset is available with
Workshop environment that controls the generation pro-
the relevant blocks for exchanging data with CANoe. These
cess. The generated code is then compiled and linked using
blocks primarily consist of functions for writing and reading
Microsoft Visual Studio compiler. This results in a Nodelayer
bus signals, system variables and environment variables. In
DLL that implements a CANoe-internal API and can be
addition, they contain blocks for calling CAPL functions. It
added as a component to a node in the Simulation Setup.
is also possible to react to calls of CAPL functions, e.g. to
Other examples of such components are the OEM-specific
control triggered subsystems in Simulink.
Interaction Layer and components for network management or transport protocols. CANoe loads these compo-
Offline Mode for Rapid Prototyping
nents at the start of a measurement, and they are released
This mode should be selected for very early development
at the end of the measurement. Therefore, when the model
phases, when frequent changes still need to be made to the
is recompiled, it is sufficient to end the measurement to
Access is provided directly from the model via Simulink
communication layers of each node perform network-spe-
model, and the real existing network does not play an im-
integrate the changed components in the simulation.
blocks that communicate with the bus hardware. Nonethe-
cific tasks, such as sending with the correct send type in
portant role yet. The application developer can still test
Consequently, model execution takes place entirely within
less, a number of disadvantages are associated with this
CAN or scheduling in FlexRay. Other protocols, such as NM
model behavior in relation to a fully simulated network. A
CANoe’s real-time environment. All events, such as actions
approach: >>The model is always network-specific. Although the
or TP, can easily be added in the form of OEM-specific com-
model developed in this early phase can also be re-used in
on the network, timers and user inputs, are computed to pre
ponents. The application layer of a node, the behavior de-
all later phases without needing to make any further mod-
cise cycles. The model is part of the CANoe configuration,
network and application content can be separated by
scribed by a MATLAB/Simulink model, is placed over a pure
ifications to the network.
and it is easy to transfer to other parties. Later it will be
intelligent structuring with subsystems, it is more advan-
signal interface (Figure 1). There is no more reference to the
Within Offline mode the simulation itself is started in the
shown how the model can still be parameterized at a later
tageous to have a generic model that can very easily be
specific network. The model only writes signal values to its
Simulink environment. CANoe works in Slave mode, and
time, i.e. without re-compiling. First, we will present a more
adapted to different networks. >>Additional protocol layers such as Network Management
output and reads signal values at its input. Whether the
Simulink is the master for the simulation session. The simu-
precise description of how the model is executed in CANoe.
signal is defined in a CAN message or in a LIN or FlexRay
lation is computed based on the specific computer speed.
(NM), the Interaction Layer (IL) or Transport Protocols
frame is irrelevant from the perspective of the model. This
All Simulink debug features can be used here, and there is
Model Computation in CANoe
(TP), as well as a rest-of-bus simulation, can only be
abstraction on the signal level lets users re-use their exist-
no need to connect real hardware to CANoe.
To understand model computation better, it is important to
implemented with enormous effort in a Simulink model.
ing models practically unchanged. All that needs to be done
understand the execution model in CANoe. Essentially,
is to map the model’s input and output ports to the rele-
Synchronized Mode for Early
CANoe computes in an event-driven way. In this context,
Easy access to a network can be obtained, for example, by
vant signals on the network.
Development Phases
events are incoming network messages or timers. With
using CANoe a simulation and testing software tool from
Not only can signals be exchanged between CANoe and the
This mode was also designed for early development phases,
each incoming event, the simulation time in CANoe is set to
Vector. This software is typically used to simulate the ECU
Simulink model; system variables can be exchanged as well.
in which the model has not yet attained its finished state.
the time stamp of the given event. The time base is derived
network with all its nodes (remaining bus simulation). The
These are internal CANoe variables that can either be ex-
Compared to Offline mode, the Synchronized mode offers
from high-resolution, non-Windows timers at the network
3/15
Model-Based Development of ECUs
Simulink blocks. In the case of an Integrator block, this might
>>Model of the brakes
of the time stamps, even though CANoe is running under
be its initial state, or in the case of a Sinusoidal block its
>>Four wheel models
mizing variations in wheel contact forces). Results for
Windows. If a generated MATLAB/Simulink model is now
frequency, phase, offset or amplitude. A system variable, e.g.
>>Road model
the car driver: Improved safety and vehicle dynamics.
added to the configuration in the form of a DLL, it must be
representing the gainfactor of a Simulink Gain block, can
computed periodically. As mentioned above, timers are also
then be used in the analysis windows (Graphic, Data, Trace)
interfaces. This is a way to achieve a high level of precision
2) Chassis control system, including: >>Vehicle observer
events that can set the simulation time of CANoe. There-
as well as on panels, and in CAPL programs and tests. An-
>>Main chassis controller
fore a timer is set in the model, with exactly the time spec-
other advantage is the ability to fine tune the model, since
>>Four subordinate power controllers for the active
ified in the Solver settings of the Simulink model.
it is easy to vary internal parameters iteratively.
dampers
>>Maintenance of constant wheel contact zone (mini-
The observer reconstructs the non-measurable vehicle states by applying a simplified linear vehicle model (with seven degrees of freedom). The chassis control system needs measurement parameter values of the angular accelerations of the car body’s roll and pitch from two gyro
Parameterizing the Model
Viewing a Simulink Model in CANoe
The environment model is subdivided into the vehicle model
sensors, as well as the car body’s lifting acceleration from
Users often wish to modify the model afterwards, i.e. with-
MATLAB/Simulink models can be observed in CANoe, pro-
and the road model. The vehicle model is designed as a
an accelerometer. The vehicle simulation makes these pa-
out recompiling. Use cases can be sub-classified as follows: >>In the model, certain starting conditions are defined at
vided that they exist in the form of a generated compo-
multi-body model with 15 degrees of freedom. The multi-
rameters available, and they are also passed to the chassis
nent. A separate window is available for this at the specific
body model is defined symbolically with the help of a com-
controller via system variables in CANoe. The force control-
the beginning of the simulation, which may not change
node after it was configured accordingly (Figure 4). To
puter algebra system, and motion equations are derived
ler regulates forces of the active force elements, targeting
the actual model logic, but may be entirely different in
modify the model at a later time, all generated internal
from this model (approx. 4,400 additions and approx.
values specified by the chassis control system. This might
different test scenarios. Example: It might be necessary
model parameters may be moved to the CANoe analysis
20,800 multiplications). The vehicle model offers addition-
be designed as a simple PI control system for current regu-
to modify the gain factors in control loops to test
windows by drag-and-drop from the model display window.
al inputs for stimulation: Accelerator and brake pedal posi-
lation, for example.
No MATLAB/Simulink license is required for this display.
tions, engaged gear, steering angle, parking brake state
In CANoe, six simulation nodes are defined (Figure 5): These
and control target value (comfortable or sporty). These
are the “Environment simulation” node (Vehicle model), the
different control characteristics. >>The Real-Time Workshop and/or a Microsoft Compiler is unavailable, or the time required for frequent recompila-
Application Example: Simulation of an Active Chassis
parameters are passed by system variables in CANoe.
“Chassis controller” node and four “Force control” nodes.
tion is too long, or the model file itself is unavailable.
Control System with a FlexRay Bus
Driver inputs may be interactively set on a control panel
The six nodes exchange data via a FlexRay bus on the four
Here, users can still modify the models at runtime
The design of an active chassis control system, including a
with relevant controls. Suitable macro recordings may also
target forces for the force actuators and four deflections
without a MATLAB/Simulink installation.
vehicle model, serves as a challenging example. The vehicle
be used as driving profiles for automated playback. The
of the wheel suspensions. Periodic transmission of these
model should be able to simulate vehicle dynamics suffi-
road model is modeled by a lookup table containing the el-
signals over a bus represents discrete sampling with a dead
ciently realistically and serve as a platform for the chassis
evation of the road surface and surface normals. Similarly,
time in the feedback control loop. Due to its indeterminate
terize the model via separately generated DLLs – this would
control system with active dampers. The goal here is to use
the surface composition is described by a friction coeffi-
nature and its size, this often has a negative effect on con-
require continual, time-consuming reconfiguration of com-
the control system to attain the most comfortable driving
cient at all road locations.
trol quality. Nonetheless, these signals can be transmitted
ponents at the nodes of the Simulation Setup. To properly
behavior possible. The overall model is subdivided into two
Chassis control consists of a LQ controller with observer.
very reliably and without jitter using a FlexRay bus. It is also
handle these use cases, components generated for CANoe
main blocks here:
The controller computes target forces for the active force
possible to transmit these signals at a high cycle rate (2.5
were made to be parameterizable after compiling. In code
1) Environment model (environment simulation for con-
elements in the wheel suspensions. Essentially, two control
to 5 ms). This significantly improves control quality of the
generation, system variables are generated for each pa-
trollers), including: >> Multi-body model of the vehicle (mechanical vehicle model)
system goals are set here: >>Reduction in body accelerations. This results in greater
overall control system compared to a CAN bus.
rameter in the model, which CANoe then reads and writes. Model parameters are typically the properties of individual
>>Model of the powertrain (simplified engine model)
In such cases, it would be rather cumbersome to parame-
Figure 4: Model Viewer in CANoe
3/16
comfort for the car driver
Figure 5: Model of an active chassis control system
3/17
Concluding Remarks CANoe/Matlab integration enables simultaneous use of Simulink to model complex application behavior and integrate the relevant in-vehicle network within the same
Jochen Neuffer studied Information Technology at the University of Applied Science in Esslingen. Since 2002, he has been working at Vector Informatik GmbH where he is a Product Management Engineer in the Tools for Networks and Distributed Systems area.
development process. Users can work in the familiar MATLAB/Simulink environment during development and do not need to concern themselves with network-specific details.
Solver A Solver specifies the mathematical approximation method used to compute time-dependent variables in a model. Simulink provides Solver algorithms with variable step-width or fixed step-width. Solvers with variable step-width optimize the algorithm according to how quickly the data changes in the model. In an extreme case, if the Solver finds discontinuities then certain simulation time points are re-computed with a smaller step-width. On the other hand, large step-widths are used for times over which the model data does not vary greatly; this accelerates the simulation time. A Solver with a fixed step-width always computes with the specified stepwidth value. This type of Solver does not detect discontinuities. Selecting a Solver Due to the interface to CANoe, and in consideration of later code generation, the user should choose Solvers with a fixed step-width, because Solvers with variable step-width exhibit the following limi tations: > Solvers with variable step-width cannot be used for code generation. With these Solvers, it is impossible to predict when the next simulation step needs to be computed and how long it will take. This fact violates the real-time behavior that is sought on typical target platforms. This limitation applies in general and for all target platforms. > Since the Solver has no knowledge of the change in data at input and output blocks – unless they are non-deterministic bus signals – a Solver cannot optimize with variable step-width here. Three different operating modes are available for code generation with MATLAB integration in CANoe: In “Offline mode” and “Synchronized mode” both software tools are active; the simulation is started from Simulink. In “Online mode” or “HIL mode”, however, code for CANoe is generated from the model. Blockset The individual blocks of the blockset are implemented as subsystems. They consist of a so-called S-Function, which implements the specific functionality. For the most part, an S-Function is user-specific code that implements an API provided by MATLAB/Simulink. This makes it rather easy for developers to extend MATLAB/ Simulink functional features user-specifically.
Translation of a German publication in Elektronik automotive, March/2010 Image rights: Vector Informatik GmbH Links: Homepage Vector: www.vector.com Product Information CANoe Matlab Integration: www.vector.com/vi_canoe_simulation_en.html
3/18
Carsten Böke studied computer science at the University of Paderborn. From 1995 to 2004 he was a scientific assistant at the Heinz Nixdorf Institute, working in the Parallel Systems Design area. Since 2004, he has been working as a Senior Software Development Engineer at Vector Informatik GmbH where he develops tools for bus analysis and bus simulation of FlexRay systems.
Figure 1: At the push of a button, the CANoe Test Package VAG creates an entire test configuration, starts test execution and generates a report.
errors as early as possible to avoid the much higher costs of
of-bus simulation (Figure 1). So, CANoe is not only respon-
correcting them later, is proved once again.
sible for the actual test sequences; it also implements the necessary rest-of-bus simulation using the provided VAG
Comprehensive Communication Tests for ECUs Developed at Volkswagen Group
Testing at the Push of a Button
Add-Ons. Such OEM-specific extensions are generally
The VAG extension for the CANoe test and simulation sys-
available free-of-charge and consist of a simulation gener-
tem from Vector demonstrates that cost reduction and en-
ator, Interaction Layer (IL) and Network Management
hanced ECU quality do not need to contradict themselves.
(NM). To achieve full automation, the Test Package utilizes
The CANoe Test Package VAG offers an incomparably
the VH1100 to supply voltage to the ECU and the CANstress
quicker path to these desired goals for VAG developers,
disturbance module (Figure 2).
test houses and of course also in-house OEM departments. PC-based test configurations can be generated for the
Automatic Generation of Disturbances and Supply
automatic execution of high-speed CAN conformance
Voltage Control
tests at the push of a button and without further prepara-
The VH1100 is a controllable voltage supply used by the test
Identical Test Environment for both OEM and Suppliers
tion. Version 2.0 of the Test Package, developed in cooper-
system to simulate various supply situations for the DUT. It
ation with Volkswagen in Wolfsburg, Germany, conforms to
has relays for independently switching terminals ignition
OEM-specific test implementations play an important role for suppliers in the ECU development process. They are used
the latest test specifications released by the Volkswagen
(15), battery (30) and ground (31), and can make precise
to check the network conformance, assure error-free communication between the numerous ECUs and are important
Group. It covers all VW80118 test cases, which are manda-
measurements of the DUT’s current consumption. Various
criteria for the final acceptance from the automotive OEM. Suppliers of the Volkswagen Group (VAG) can now minimize
tory for VAG suppliers. The package supports both the
voltage patterns and disturbances may be simulated by re-
both ECU development times and costs using a VAG-specific test software to automatically generate high-speed CAN
current and previous versions of the VW80118 test specifi-
mote control via USB, to examine DUT behavior in reaction
tests according to the VW80118 specification.
cation.
to overvoltages, undervoltages and voltage interruptions.
The CANoe Test Package VAG consists of a test configura-
The hardware module CANstress is used to simulate digital
tion generator with configuration dialog, CAPL (Communi-
and analog disturbances on the CAN bus. This USB-hard-
cation Access Programming Language) test libraries for
ware is connected directly to the bus line and is used to
ECUs not only need to fulfill their required functionality, but
of the tests are not insignificant considering the growing
UDS (Unified Diagnostic Services) and KWP (Key Word
reproducibly manipulate physical properties and logical
must also fit seamlessly into the ECU environment – while
complexity of automotive electronics. Test applications
protocol) as well as the VAG Interaction Layer for the rest-
levels. Flexible trigger and disturbance logic lets users
considering special OEM-specifics. This is why intensive
must be created and maintained, or else a testing facility
communication tests are needed in addition to the func-
must be hired. Finally, each new ECU and each modifica-
tional tests. Such tests investigate the ECU’s behavior, not
tion requires making extensive changes to the created
only under normal conditions, but in numerous error situa-
tests. Problematic with this process is that some details of
tions as well, for example: drops in supply voltage, recep-
each party’s test implementation – whether supplier, test-
tion of faulty messages, protocol violations during trans-
ing facility or OEM – may deviate to a greater or lesser de-
mission, irregularities in cycle times and disturbances in bus
gree. If tests yield different results in reference to the latest
voltage level due to short circuits.
test specification, time-consuming troubleshooting will follow. Furthermore, it is then necessary to address the un-
3/20
Reproducible Testing at the Supplier
pleasant question of who is responsible for the caused
The supplier assumes primary responsibility for correct and
problem. Errors do not necessarily have to be caused by the
reproducible behavior of the Device Under Test (DUT) under
ECU itself; gaps are also possible in the specification itself
all of these constraints. The costs for the implementation
or its interpretation. The conventional wisdom of detecting
Figure 2: Time-synchronous real-time acquisition and visualization of internal ECU signals via CCP/XCP, and of signals from CAN, LIN and FlexRay buses and external measurement equipment via CANape.
3/21
Comprehensive Communication Tests for ECUs Developed at Volkswagen Group
file contains detailed information on the ECU. A new file must be created for each ECU, which provides information about the ECU in XML format. This information includes a
Klaus Theobald is Senior Software Development Engineer for the “Tools for Networks and Distributed Systems” product line at Vector Informatik and has developed the VAG Test Package.
list of the Tx and Rx messages, diagnostic parameters, Diagnostic Trouble Codes (DTCs), specification versions, etc. The TBD file supplies information about a VAG ECU that is needed to properly configure VW80118 tests. The supplier may also add information to this file using an editor provided by VAG, e.g. to add DTCs. The test configura-
Gavin C. Rogers is Team Manager in the “Tools for Networks and Distributed Systems” product line and Product Manager for CANoe Test Packages.
tion generator reads the TBD and DBC files and uses them to generate the CANoe test configuration (Figure 2), which consists of the remaining bus simulation and an XML test flow module. Clearly Represented HTML Test Reports Figure 3: Test execution control of the VW80118 test
Up to several hundred test cases may be generated, depending on the number of Tx and Rx messages (Figure 3). Each test case returns a detailed HTML test report (Figure 4)
destroy any desired bit positions of CAN messages and
and log files in ASCII format. The test reports are organized
manipulate bit fields. Full remote control capability via
with section numbers corresponding to those of the VAG
COM (Component Object Model) makes a valuable contri-
test specification. Color highlighting of errors gives users a
bution toward automating VAG tests.
quick overview of the success or failure of executed test cases.
OEM Delivers Test Base to Suppliers One of the key requirements for successful configuration of
Summary and Outlook
the test environment is a consistent description of ECU
The CANoe Test Package VAG – together with the VH1100
communication in the form of the TBD (Test Basis Docu-
test hardware and the CANstress module – creates a
mentation) file and the CAN network database (DBC). The
cost-effective test environment based on standard CAN
OEM creates these two files and passes them on to the
tools. The described solution lets developers, suppliers and
supplier. While the DBC file stores OEM-specific informa-
test houses perform the same tests as the OEM with mini-
tion on the network and rest-of-bus simulation, the TBD
mal effort. The automated generation of configurations and test sequences saves time and reduces the development costs. At the same time, OEMs and suppliers benefit from early error detection, fewer iterations and improved quality. The CANoe Test Package VAG is the only test system available on the market that is certified by VW for high-speed CAN conformance tests and is explicitly recommended for in-house testing at suppliers. An extension of the existing solution by adding globally applicable VAG test specifications – such as for network management messages (NM-High) – is already planned for the next version. Translation of a German publication in Hanser automotive, October/2010 Image rights: Vector Informatik GmbH Links: Homepage Vector: www.vector.com Product Information CANoe Test Package VAG:
Figure 4: Detailed report example for a successful test case
3/22
ww.vector.com/canoe_tp_vag
3/23
To flexibly cover all of these requirements in the E/E con-
ered from a later milestone in the testing process. The MUX
cept, EvoBus developed a scalable multiplex system (MUX
system itself is a scalable peer-to-peer system. The number
system). Consisting of up to nine modules, the electronics
of MUX modules used in the vehicle depends on the select-
architecture of this MUX system is a type of distributed sys-
ed equipment versions and special customer wishes. Each
tem within a distri-buted system. The hardware and firm-
MUX module has a number of largely configurable digital
ware of the MUX system are a sort of middleware that pro-
and analog inputs and outputs. The MUX modules are in-
vides the fundamental components and tools for application
terconnected via the CAN buses to form an overall system
development. This middleware is user-programmable by
(Figure 1).
the use of IEC61131-conformant and OEM-specific logic
With the help of the VT System, EvoBus engineers test the
chips, and it is positioned beneath the application level. The
fundamentals of extensive functions such as valve control
individual MUX modules are distributed to different bus
for automatic suspension leveling, door control ECUs for
branches of the overall vehicle network that consists of five
the luggage compartment and engine compartment doors
main CAN buses for powertrain, chassis, interior, telemat-
and the complex interior lighting system. The latter also
ics and diagnostics areas as well as numerous LIN subnets.
leaves much freedom for fulfilling customer-specific wishes. A key challenge is network management. Status transi-
Test Bench for Complex ECU Networks Individuality of Omnibus Features Requires a Flexible Test System ECU tests may be very complex depending on the work area and the range of functional features. This is even more relevant when testing must cover a network of five to nine ECUs whose functionalities are inseparably intertwined and vary according to the vehicle type, features and special customer wishes. That is why EvoBus has started up a new component test bench based on the VT System from Vector. Its flexible, automated tests enable a high level of test coverage and precise reproducibility of all test cases.
In the omnibus area, the challenge is to create a vehicle
flexibility of the architecture in the body and convenience
that fulfills the technical requirements of commercial vehi-
electronics areas. Very low volumes in comparison to the
cle while providing a level of comfort and convenience at
passenger car industry makes re-use desirable in all model
least equal to that of a passenger car. The focus here is on
series (urban, long-distance and tour buses). Synergy effects
the development of platform systems that implement up
are exploited and costs are reduced by using standardized
to 120 functions on a common hardware unit. Their com-
adaptable hardware.
plexity ranges from “very simple” to “very complicated.” The
In some respects, the E/E requirements of omnibuses differ
many possible combinations of individual functions are an-
significantly from those in the passenger car area, because
other requirement. A high level of customization and con-
the features of an omnibus are determined by individual
sideration of specific special customer wishes, sometimes
customer wishes to a far great extent. This must be consid-
even shortly before delivery, require special modularity and
ered in the E/E concept, which requires especially well
Testing Challenge: ECU Network of up to Nine Modules
tions such as wake-up from the power-down mode, and in
The scope of testing is exceptionally high, due to the high
the opposite direction, shut-down of the network must run
functional density and numerous degrees of freedom in
trouble-free and in correct interplay with the application
configuring the MUX system. To optimize the time-inten-
and hardware. Besides simulating the CAN communication
sive and complex test phase, EvoBus 2011 started up a new
of the remaining bus, OSEK network management is also
test bench that is individually customized for the needs of
simulated here. Since each MUX module always needs to
the MUX system. The test bench is based on the VT System
be informed of the current system states of other MUX de-
from Vector. It is capable of simulating all components and
vices in a timely way, synchronization processes are contin-
system states of the MUX environment that are required
ually taking place. In the exchange of process images, spec-
for the tests. They include both the signals of the numerous
ified timing and real-time requirements must be fulfilled,
hardware inputs and outputs as well as the CAN and LIN
and this represents another test criterion.
communication. Serving as a user interface is a PC with CANoe test and simulation software from Vector.
Simulating Environments and Automating Tests
After tests by the supplier, component tests represent the
The MUX system must also be tested to determine whether
first step in the test process chain within the V-model,
it can operate smoothly with various hardware changes.
which ranges from component testing to software module
Test contents include data and diagnostic routing of the
tests, Hardware-in-the-Loop and finally trials in the real
Sub-CAN and Sub-LIN buses of the MUX system. Testing of
vehicle. In component tests, the focus is on correct func-
diagnostic functions requires special attention here: The
tionality of the middleware, while the application is consid-
I/O channels of the MUX system permit flexible and varied
thought-out modularity and flexibility. The electronics About EvoBus The EvoBus company and the two omnibus brands Mercedes-Benz and Setra have been merged under one umbrella company since 1995. EvoBus is a subsidiary of Daimler AG, which is active in the omnibus business area. With a market share of 50% in Germany and 21 % in Europe, Daimler is the market leader in the segment of buses over 8 metric tons. [Revised: 12-31-2011]
3/24
(hardware) should lend itself to broad-based use within the overall range of omnibus products as much as possible and be adaptable in a cost-effective way. Other challenges include improving fuel economy, reducing exhaust emissions and performing advanced development of active and passive safety and assistance systems.
Figure 1: Example of a distributed function in the MUX system - side marker light.
3/25
Test Bench for Complex ECU Networks
configurations of the compact bench-top device that range
Real-Time Capability by Modular System Layout
to a DOORS database in which the test specification is
ber of diagnostic test cases is large. Testing the trouble
to a large HiL system for the test laboratory (Figure 2). The
The remaining bus simulation utilizes the OEM package for
stored. After test execution on the VT System, the results
codes of the MUX system itself currently requires imple-
VT System implements comprehensive emulation of the
the Daimler-specific interaction layer and OSEK network
are documented back into the database in XML format and
mentation of 1,000 of the most important test cases.
ECU environment with regard to input and output circuitry
management. This assures full emulation of the sending
saved. This assures traceability of abnormal findings, their
However, system variability can require more than ten
as well as communication of the connected CAN and LIN
behavior as well as realistic communication behavior on the
correction and statistical information about the test object
times the number of permutations. This task cannot be
buses.
data buses with low effort. Real-time relevant tasks, and
for every sample level. Universality of the tool chain and
performed manually and still be economical. The VT System
The main advantage of emulation is that the behavior of
the remaining bus simulation test sequences, are executed
minimizing the number of interfaces were important to
now enables automated execution and documentation of
drivers, passengers, vehicle equipment and other environ-
directly on the VT6050 real-time module. In turn, the
EvoBus. These requirements are fulfilled by the Vector ap-
this test within a few hours.
mental components can be simulated reproducibly. Testing
VT6050 is connected via Ethernet to the CANoe host-PC
proach, from definition of test requirements to test execu-
The complexity and diversity of the MUX tests can only be
of door control, for example, requires repeated actuation of
that is used for user interactions and for viewing and anal-
tion and evaluation of the reports.
economically handled by systematic automation of test se-
a pushbutton to open the omnibus door at precisely de-
ysis. This distribution of work makes an important contri-
In testing the MUX ECU network, the efficiency gains real-
quences. The VT System, which is modularly built in 19” in-
fined times. Instead of manual actuation, these actions are
bution towards attaining the extraordinarily high scalabili-
ized by the VT System are enormous. Extensive tests, which
dustrial rack format, is optimized for the characteristic
performed by the test system. This assures the proper tim-
ty of the overall test system (Figure 3).
required about two weeks before – including preparation of
tasks of test automation and, with six modules, it permits
ing sequences and is reproducible at any time.
configuration of diagnostic behavior. As a result, the num-
the specific test software – can now be completed in one Standard Tool CANoe as Front-End for Test Bench
day. The pins of the ECUs were previously fed into specially
Scalable Test System Enables Customized Hardware
CANoe on the desktop PC serves as a platform for all user
fabricated purely passive test boxes that had to be manu-
Layout
operations, test definitions and evaluation actions. The dual
ally rewired for each individual test. Since this approach
The system supports all commonly used analog and digital
monitor setup at EvoBus offers sufficient space for a well-
could not be automated, it offered far few testing options
input and output standards including more complex func-
organized display of the main program windows, output
and was inherently more susceptible to errors. When tests
tions such as generating and processing PWM signals and
pins, input pins, measurement value displays, etc. CANoe
needed to be repeated, personnel resources were tied up
determining effective values. While load and measurement
has become established as an industry standard for elec-
for longer periods of time. With the VT System, on the
modules of the VT1004 type are connected to the outputs
tronics development related to automotive applications,
other hand, it is possible to reproduce test runs at the press
of an ECU, the VT2516 and VT2004 modules contain the
and it offers numerous functions from which the MUX
of a button. Today, using the new system, EvoBus has now
electronics for stimulation of digital and analog inputs.
modules benefit. The intuitive user interface has made
performed 500 individual tests (without diagnostics) with
VT7001 power supply modules regulate the operating volt-
training in user operation of the test bench run quickly and
greater test depth, test coverage and precision, where pre-
ages and measure the current consumption of the MUX
smoothly. All parameters of the VT System are accessible
viously only about 100 spot check type tests could be per-
modules. In addition, VT6104 modules are used for the net-
from CANoe. Vector’s ‘Test Feature Set’ meets the criteria
formed. Another positive aspect of the test system is its
work communication of the CAN and LIN networks. The
for high-performance test automation. In addition, test se-
tremendous flexibility. The VT test bench is not only used
VT6050 PC module is the CANoe Realtime-PC, on which
quences can be defined, tests executed and reports gener-
for automated testing of new software versions. It also
the simulations and tests are executed. Only the input/out-
ated. In generating and executing reproducible test cases
serves as an analysis tool for feedback on abnormal find-
put level of the EvoBus test bench – which is built in a 19”
for the diagnostic protocol, CANoe Option DiVa (Diagnos-
ings to Customer Service and Production. Such situations
control cabinet – consists of five logical levels that are each
tic Integration and Validation Assistant) performs valuable
require quick reaction. Therefore, the hardware can also be
fully populated with twelve VT System modules. Currently,
services. The Test Automation Editor contains an interface
run manually over a CANoe user interface without having
the system covers requirements for five of the nine possible
to write test scripts; in this way, it can be spontaneously
MUX modules. The control cabinet also has a patchboard
used to troubleshoot problems and correct them.
that provides individual access to all input pins of the MUX
Figure 2: VT System as component test bench of the Evobus MUX system.
3/26
ECUs for manual measurements; break-out contacts for all
Further Extension of the EvoBus Test Bench Planned
CAN/LIN buses are also provided.
The VT System at EvoBus with its fully featured, approxi-
Comprehensive ECU tests generally also include test se-
mately two meter tall control cabinet is one of the larger
quences in which conditions prevail that deviate from nor-
VT System projects implemented by Vector. The project
mal operation. That is why the VT System was designed to
timeframe from the specification phase to startup and
generate defined errors in the ECU environment, e.g. de-
training amounted to about five months. The progressive
fective sensors at the inputs or atypical load behavior of
development of new vehicle types and the introduction of
actuators connected to the outputs. Upon request, the sys-
hybrid drives will make an extension of the test system
tem can generate line breaks and short circuits in feed
necessary. EvoBus plans to extend the test bench by adding
lines, short circuits to ground and battery potential or
an input/output module. The test bench will then be able to
over-voltages and under-voltages. The five electronic loads
test MUX systems with up to six modules. It will then be
represent a special feature. They can each conduct a cur-
necessary to supplement the system with a second control
rent of ten amperes as a source or sink, so that the MUX
cabinet. This represents an intermediate step towards full
system can be supplied with enough power for special test
implementation of a system that can handle nine modules.
cases.
That is because the functional features of large tour buses Figure 3: Schematic diagram: Layout of the MUX test system.
can assume considerable dimensions, where comprehensive testing is always required for the electronics of com-
3/27
fort/convenience functions, climate control, interior lighting, distributed functions for hybrid vehicles, fast door opening and closing mechanisms, entertainment systems and other features. Translation of a German publication in Elektronik automotive, October 2012
VN8900 Converting Test Benches Worldwide in Record Time Case Study ZF TRW
Links: Homepage EvoBus: www.evobus.com Homepage Vector: www.vector.com Product information VT System: www.vector.com/vt-system Product information CANoe: www.vector.com/canoe Michael Schneider, EvoBus He earned a degree in General Electrical Engineering from the Ruhr University at Bochum and RWTH Aachen, Germany. Since 1998, he has been employed as a system developer in the Basic Systems area of DaimlerBuses.
The Customer
radar and camera systems in the field of autonomous
ZF TRW is one of the world’s largest automotive suppliers.
driving.
It supplies over 40 prominent automotive OEMs with advanced systems related to vehicle safety. They include brake,
The Advantages
steering and wheel suspension systems as well as complex
Drastically reduced setup times – faster projects > Test stands fit seamlessly into ZF TRW tool chain
occupant protection systems and on-board electronics.
> Remaining bus simulations can be reused in tests with Philipp Merkle, EvoBus He earned an engineering degree in Industrial Electronics specializing in Vehicle Electronics from the Technical College in Ulm, Germany. Since 2007, he has been working as a test engineer for Central Electronics at DaimlerBuses.
Katja Hahmann, Vector Earned a degree in Electrical Engineering from the Technical University in Chemnitz, Germany. In 1997, she joined Vector Informatik in Stuttgart where she is group leader in CANoe application development for the Networks and Distributed Systems product line.
The Challenge Configure test benches used to test various ECUs world-
just minimal modifications > Setup times are drastically reduced
wide with shorter setup times
> High level of stability and durability in long-term tests
At ZF TRW, the cost and effort required for ECU testing
> Inexpensive CANoe stand-alone extended license enables
was continually increasing, because of both the number of
autonomous operation of the VN8900 > Broad and free support of the required OEM-specific
ECUs and their extended functionality. Each ECU must pass countless electrical, functional, mechanical, environmental and EMC tests before product release. Test bench engineers were seeking a more flexible solution that would address this growing complexity, meet future needs and conform to available timeframes. The solution was to be implemented globally and uniformly at all business sites.
protocols by Vector > Free updates of VN8900 to new CANoe stand-alone versions
Rugged Data Logger Endures Tough 24h Race
The Solution Intelligent network interface is central focus The modular VN8900 network interface from Vector plays
Case Study GETRAG
a key role in the new concept of component-based test benches. Along with its high performance, it offers the additional crucial advantage of automated operation. CANoe remaining bus simulations and test sequences can be run CANoe stand-alones without having to connect a separate PC for CANoe control. Each test stand consists of a 19” cabinet with six plug-in rack modules, and each rack module integrates a VN8900. This means that each test stand can test up to six ECUs in parallel. CANoe remaining bus simulations that already exist in the development departments can be reused in the tests with just minimal modifications. The new approach reduces setup times drastically: from as many as eight months to change an ECU tester over from OEM1 to OEM2 to a time of two to three weeks. The time needed for changes shortly before the start of testing was also reduced: to less than one week. A total of 32 test benches are currently in use worldwide at ZF TRW. In the future, they will also be used for tests of 3/28
www.vector.com/contact
The Customer
Th
With a history of producing 2.6 million transmissions, the
A
Block circuit diagram of one Group of the six a test stand GETRAG Corporate israck onemodules of theinlargest transmis-
m >
sion manufacturers in the world. In 2008, the company successfully launched the GETRAG PowerShift® dual-clutch transmission on the market, which is installed in such cars
>
as the Mitsubishi Lancer Evolution X.
> The Challenge Reliable acquisition and quick evaluation of measured data
>
in a challenging car racing application
>
The objective was to put the GETRAG PowerShift® transmission to the test in a Mitsubishi Lancer Evolution X during the ADAC Zurich 24h car race to evaluate its durability and racing performance. Six different CAN control modules were used to reliably and quickly log measured data throughout the race for performance analysis.
3/29
V2.0 | 2015-08
on the VN8900 with the cost-effective extended license for
>
ment to meet performance and operating convenience
ables or environment variables. The Simulink® Real-Time
requirements. Advanced development of the next genera-
Workshop® generates a Windows® DLL that is loaded in the
tion tire pressure control system involves a model-based
CANoe simulation environment. The CANoe Interaction
development application on a new high-performance hard-
Layer handles sending of messages according to the send
ware platform. For the driver, this means increased operat-
behavior stored in the database. Finally, the test sequences
ing convenience: In Automatic mode, the operator simply
are created and automatically executed with the CANoe
selects the terrain type, and the system automatically en-
Test Feature Set.
sures correct pressure in all tires via a 4-channel pneumatic
This is followed by initial tests in the vehicle. Previously,
system.
these tests were not possible until the availability of prototype ECUs or so-called Rapid Prototyping Platforms. When
PC-Based MIL Tests
CANoe is used with the integrated application model, this
In developing the new tire pressure control system, first a
enables in-vehicle testing of the operation and display con-
model of the new pneumatic system (“plant model”), in-
cept without requiring a special hardware setup. CANoe is
cluding the tires, was created and verified based on mea-
responsible for CAN communication with the vehicle. A sen-
sured data and design documents. This was followed by
sor/actuator module, in this case the current level ECU,
initial implementations of the application model. Daimler
makes I/O functionality available in the vehicle over CAN.
hired the company ITK Engineering to create the MATLAB/
Test sequences that have already been created can be re-
Simulink models. The models realistically simulate the
used for this purpose. The first Software-in-the-Loop tests
dynamic behavior of the real system. Pressure sensors con-
(SIL tests) are executed early in a phase in which require-
tinually acquire the pressure of individual tires, which are
ments have not all been fully described yet.
always interconnected with the pneumatic system via a
Hardware Simulation for the Challenging Unimog Tire Pressure Control System Time Savings and New Options by ECU Tests on the Model
central air channel in the portal axles. Another sensor
The Path to the Component HIL Test Bench
serves as a reference for the system and automatically ver-
Since the developers would not always have access to a
ifies the sensors that have fixed assignments. Also included
test vehicle, Daimler decided to procure a component test
in the model are momentary pressures, compressor power
bench based on the VT System test hardware from Vector.
and channel cross-sectional areas, etc. The relationships,
The system is tailored to the needs of the automotive in-
including effective time constants when increasing and
dustry. It is a modularly configurable and powerful test sys-
reducing tire pressure, are computed precisely in the model.
tem for uses ranging from a small bench-top setup to a
As a result, PC-based Model-in-the-Loop tests (MIL tests)
large HIL system in the laboratory. In the VT System, the
are already possible in this development phase.
focus is on simulating the sensors and actuators connected
Increased traction, minimized fuel consumption and avoidance of site damage: These are good reasons to always drive
to the ECUs as well as simulating potential error situations
off-road utility vehicles with tire pressure adjusted for specific conditions. Developers at Daimler AG used a new type of
Simulink Models in SIL Tests
such as short circuits, overvoltages and undervoltages. The
test system for realistic tests of the next generation tire pressure control system for off-road Unimog vehicles. The test
The model-based approach is also taken in subsequent de-
system is set up modularly with various VT modules for
system simulates all sensors and actuators of an ECU’s environment and enables comprehensive HIL tests, including
velopment phases. By integrating the models in the CANoe
load simulation, measurement and stimulation. Another
simulation of fault situations in the environment’s hardware and wiring.
simulation and test tool from Vector, model behavior is
important factor in the decision to use this hardware was
tested in conjunction with bus communication. Using the
that it would be optimally integrated in the CANoe soft-
While high tire pressure ensures low rolling resistance and
CANoe blockset for MATLAB/Simulink, the model inter
ware system already in use at Daimler for many years. In
largest commercial truck manufacturers in Europe. Besides
fuel consumption on pavement, other properties are pre-
faces are connected directly to bus signals, system vari-
particular, direct integration of these modules in CANoe
producing the well-known Mercedes-Benz Atego, Axor and
ferred in off-road driving. For example, when driving on a
Actros trucks, Daimler AG also develops and manufactures
wet field reducing the tire pressure also reduces tire con-
special purpose vehicles such as the Unimog, Econic and
tact pressure, so that no appreciable site damage occurs
Zetros.
(Figure 2). When it comes to available traction, there is a
The Unimog U3000/4000/U5000 product line achieves
direct relationship between soil composition and the tire
extreme off-road mobility with portal axles, coil springs,
pressure used. By reducing tire pressure off-road you can
manually selectable all-wheel drive and thrust-tube tech-
easily double available traction. This could be a crucial fac-
nology; its performance capabilities include a maximum
tor in determining a task’s success or failure. In addition,
fording depth of 1.20 m (Figure 1). Low-emitting diesel
low tire pressure can contribute to better self-cleaning of
engines with power outputs ranging from 110 kW (150 PS)
the tires, because of the tire’s greater deformation.
The business site at Wörth am Rhein is home to one of the
to 160 kW (218 PS) are used for the drives. One of the spe-
3/30
cial features Mercedes Benz offers in its program is the
Model Based Development of the Tire Pressure Control
“tire control” option. This is an electro-pneumatic system
System
for inflating and deflating the tires that lets the driver
The electronic concept that was successfully applied to the
modify tire pressure right from the cab.
Unimog series is currently undergoing advanced develop-
Figure 1: All-terrain mobility is the primary feature of the Unimog
Figure 2: Tire pressure control while driving is possible, e.g. to avoid site damage
3/31
Hardware Simulation for the Challenging Unimog Tire Pressure Control System
would make it easy to perform later extensions or modifi-
tremendous interest to Unimog experts in their efforts to
cations to the system for new projects. The test system is
further develop the system, as is information on whether
connected to the test computer via its Ethernet port, utiliz-
the ECU generates correct entries in error memory.
ing the real-time capable Ethernet protocol EtherCAT®. CANoe permits access to all parameters of the VT System
Outlook
and is the tool for test automation (Figure 3).
In testing the tire pressure system at Daimler, it no longer
For HIL tests on the real ECU, the plant model is integrated
makes any difference whether a real or simulated ECU is
in CANoe. Another advantage of using models is revealed
tested. Developers also enjoy independence from the avail-
here: Any desired initial states may be produced essentially
ability of real test vehicles. As a result, the test system can
“at the press of a button”. In the plant model, this relates in
be used universally – from the design phase to functional
particular to the pressure in the tires and in the pressurized
tests. This is what is required if test results for the ECU are
reservoir. That is because in tests on real vehicles it may
to be directly comparable.
take 20 minutes or so until 4 flat tires are filled back to their
Motivated by the success of the VT System in the tire pres-
specified operating pressure when a vehicle air compressor
sure control system, developers in Wörth are already plan-
is used. The laboratory test system, on the other hand, is
ning their next projects. They include advanced develop-
capable of doing this immediately. It addresses parameters
ment of the hydrostatic traction drive, in which the system
of the model directly and represents values such as pres-
is extended by 16-channel digital modules and the power
sure curves graphically.
supply module.
VT System as HIL Test Bench Component
Translation of a German publication in Elektronik automotive,
The plant model is integrated in the CANoe Simulation via the CANoe Blockset - the real ECU is being tested here. All
Figure 4: Modular setup of the VT System as a component HIL system
June 2010
ECU inputs and outputs are connected to the relevant bus
Image rights:
signals or hardware channels of the VT System. Communi-
Cover picture: Daimler AG
cation between the CANoe Simulation and the Simulink
Figures 1 - 2: Daimler AG
models occurs directly via a signal interface or via CANoe
for meaningful tests, either the original sensors and actua-
environment and system variables. As a standard feature,
tors are necessary, or else the ECU’s environment must be
the ECUs check their inputs and outputs to verify that the
simulated as realistically as possible. However, because reason
Links:
relevant components are actually connected and that sen-
able test automation with original components involves
Homepage Daimler: www.daimler.com
sor data or termination resistors are plausible. Therefore,
enormous cost and effort, e.g. when controls are operated
Homepage Vector: www.vector.com
by robotics, simulation of the environment is generally pref-
Product Information VT System: www.vector.com/vt-system
erable. The VT System is now responsible for simulating the
Product Information CANoe: www.vector.com/canoe
Figures 3 - 4: Vector Informatik GmbH
environment hardware. The VT2004 stimulation modules apply the relevant voltage values to ECU inputs to which the tire pressure sensors are connected in the real vehicle. The switches for inflating and deflating the tires can be simulated as well. On the other hand, the VT1004 load and
Mario Wirmel, Daimler AG initially worked in Production Planning at Mercedes-Benz Trucks in Wörth; since 2003 he has been working in Electrical/Electronic development in the Special Vehicles product area at Mercedes-Benz.
measurement modules are used to simulate valves by electronic loads or measure the values at the ECU outputs. CANoe also handles the network simulation and test automation. This so-called Component HIL Test bench (Figure 4) for testing an individual ECU is re-used later for tests in the
Katja Hahmann, Vector since 1997 she has been employed at Vector in Stuttgart where she is group manager for CANoe Application Development in the Networks and Distributed Systems product line.
real vehicle as well. The focus of the new test system is to simulate error situations caused by incorrect wiring, defective sensors, actuators, etc. These components do not supply any values or they supply incorrect values, or they may have internal resistances and current consumptions that deviate from specification. In the case of pressure sensors, for example, voltages outside of the measurement range are generated, electronic loads simulate the valves and current consumpFigure 3: Layout of the component HIL test bench
3/32
tions deviating from normal values can be parameterized. The ECU’s reactions to such unpredictable events are of
3/33
their algorithms. With the XCP protocol standardized by
outputs, they also provide an in-depth look into the ECU’s
ASAM, the user can read individual values directly from the
memory (Figure 2).
ECU’s memory as needed. The protocol can also supply a
In simple analysis tasks, users can display the data in the Trace
defined set of measured values synchronously to the ECU’s
or Graphic window and use panels to evaluate the results.
application via so-called Data Acquisition (DAQ) lists. The
For more complex test sequences, the tool vTESTstudio of-
XCP protocol was defined for efficient provision of data
fers extensive options for creating CANoe test cases that
over the bus medium. As an example, after configuration
perform automatic evaluations. For example, this enables
the DAQ lists can be transmitted in response to a single
checking of the Network Management state machine for
identifier from the test system. In addition, measurement
correct functionality. The necessary stimulation is per-
times of the DAQ lists can be optimized to internal ECU
formed in the CANoe rest-of-bus simulation, and the ECU’s
processes. Automated test systems place similar require-
reaction is not just measurable on the bus; it is directly
ments on the system. Use of the XCP protocol makes it
measurable in the ECU over XCP.
possible to integrate internal values in test sequences with-
The effort required to execute test cases is also significant-
out excessive loading of the ECU or the bus system used.
ly reduced, e.g. for test cases that require sensors. The test
Another reason that a widely used standard like XCP is
system writes the sensor values directly to memory cells in
ideal is that it is very easy to configure in the tool chain. All
the ECU over XCP. This eliminates the need to connect and
necessary information is already in the A2L file such as in-
control original sensors at the ECU inputs – a demanding
ternal program memory locations with their names and
task. The ECU is notified that the sensor and associated
communication parameters. Depending on the develop-
hardware driver have measured the values correctly. The
ment environment, the A2L file is either automatically gen-
same approach can be used in the other direction. Here it is
erated. As a second step, after compilation memory ad-
assumed that the output stage and actuator have been
dresses are taken over into the A2L file from the linker-
tested and accepted. In this case, the test system mea-
map-file. In the test tool, the user only has to configure this
sures the value that the application prescribes to the driver
file once for each ECU used in the test. In a second step, the
stage over XCP.
user selects the symbols needed for the test sequences
ECU Testing with XCP Support
from the A2L file.
Access with Large Quantities of Data If large quantities of data need to be exchanged between
A Look behind the Scenes
CANoe Option .XCP
the test system and the ECU in a test case, or if especially
Blackbox tests are typically conducted in the framework of ECU development or in analyzing faulty ECU behavior. This
Option .XCP supplements the CANoe test tool from Vector
quick processes need to be monitored, an XCP connection
with the convenient option of reading or writing internal
over the CAN or FlexRay bus is no longer effective. In such
ECU values. Besides supporting the standards XCP in CAN/
cases, direct access to the ECU’s debug interfaces is
involves connecting an ECU‘s inputs and outputs to a test system for stimulation and measurement. Although this method lets the test engineer perform extensive analysis, certain tests require looking directly into the ECU. This is the only way to obtain meaningful test results or reduce testing effort.
CAN FD, XCP on FlexRay, and XCP on Ethernet, it also sup-
recommended. This could be implemented via a NEXUS or
ports the previous protocol CCP. Once the A2L file has been
JTAG interface, for example. These protocols access the
configured and the necessary values selected, CANoe auto-
ECU memory directly – in part by using the microcontrol-
In most cases, it is actually sufficient to look at the ECU’s
additional bus load, and in the worst case they might even
matically acquires them and maps them as system vari-
ler’s debug-trace. Taking this approach, the user can quick-
inputs and outputs to functionally test a component
collide with messages of other system components.
ables. The user can then use these variables in any of the
ly read out very large quantities of data from the system
(Figure 1). However, this becomes difficult when state
Another way to access internal values is through diagnos-
testing tasks. Besides offering access to ECU inputs and
without loading the bus or the ECU.
machines are used in the ECU. Their current states can only
tics (Figure 1). Some information is available directly via
be derived indirectly by their effects at the ECU’s outputs.
diagnostics, e.g. diagnostics offers access to fault memory.
In the case of sensors whose values are not transmitted
Special diagnostic services are also provided to read the re-
over the bus system, it is also very difficult for the test en-
quired values from memory. The advantage here is that a
gineer to localize errors to the software interface. From
standardized access method is used. The only precondition
outside the ECU, it is not clear exactly where the sensor
is full integration of the diagnostic driver; this is generally
value was incorrectly processed.
provided in today’s ECUs. The disadvantage of this method
Different methods that offer access to internal ECU data
is that a lot of diagnostic protocol information is transmit-
are used, depending on the phase of ECU development. In
ted along with the actual measured values, and this adds
early phases, for example, internal ECU values are often
load to the bus system interface.
output in so-called “reserved development messages”
3/34
(Figure 1). For the functional developer at a supplier, this is
XCP for Test Access
an effective and quick method that precisely targets a spe-
If bus load needs to be kept low, an alternative is to use a
cific objective. However, these supplemental messages
calibration protocol. Originally, such protocols were devel-
must be removed for later development phases, especially
oped for the ECU calibrator. They let calibrators modify
for system integration and series production. They induce
parameters or characteristic maps in the ECU to optimize
Figure 1: Conventional test system for ECU testing with limited access to an ECU’s internal values via diagnostic functionality or special messages created by the developer
Figure 2: Option .XCP is used with a CANoe test system for direct access to an ECU’s internal values.
3/35
Vector VX hardware, for example, offers direct access to an ECU’s NEXUS or JTAG interface (Figure 2). Since this hardware communicates with the test system via XCP-on- Ethernet, integration in CANoe is as easy as integration for XCP access over CAN. Combining VX hardware with the CANoe test system further improves test system performance, without any negative effects on the communication medium. Updated article – translation of a German publication in Automobil Elektronik, June 2010 Image rights: Vector Informatik GmbH Links: Homepage Vector: www.vector.com Oliver Falkner studied Electrical Engineering at the University of Stuttgart. After graduating, he joined Vector Informatik GmbH in Stuttgart in 1999 where he is currently Manager in product management for the Networks and Distributed Systems product line.
3/36
>>Report all trouble codes that fit a specified status mask
for trouble code XYZ, check whether it is active and whether
>>Read the status and environmental data for a specific
the voltage was between 11.5 and 12.5 Volt when the error
trouble code >>Clear the status and the environmental data for a group
occurred!” The test code for this function would be extremely compact and clear.
or an individual trouble code The service department tester generates a diagnostic re-
Efficient Access to Fault Memory
quest and sends it to the ECU. The ECU responds with a
The described abstraction level might, for example, be
diagnostic response. The response usually contains multiple
provided by the CANoe test tool in combination with the
error messages with their trouble codes, the associated
Test Automation Editor test design tool. Both are software
status masks and environmental data (Figure 1). All data
products from Vector, and they support both the UDS and
must then be evaluated. Causes of errors can be very quick-
KWP 2000 protocols.
ly localized with the prepared information, and the defec-
A number of test functions are intended for fault memory
tive component can be replaced.
tests, and they can: >>Read out individual trouble codes with their environ-
Testing Fault Memory Functions
mental data, check them and document them in a test
One strength of fault memory is that the vehicle provides
report. If necessary, allowable trouble code combina-
the algorithms for detecting error states. However, this
tions or alternatives can also be shown. >>Read out all trouble codes that have a specific status
assumes that the vehicle’s diagnostic functionality itself is operating correctly. Consequently, this functionality must be intensively tested during the vehicle’s development.
mask >>Clear the fault memory
Tests of diagnostic functionality can be very complicated
>>Read out the supported trouble codes
due to the very large number of existing trouble codes, and
>>Read out the status of the fault memory
the extensive environmental data and error states. This is
Efficient ECU Tests with Fault Memory Vehicle diagnostics is a very useful yet very complex topic over a vehicle’s development and service life. Development and service department times can only be minimized if reliable, correct and precise data is available at all times. Suitable test tools are needed to reach this high level of quality while developing ECUs and their diagnostic functionality. This article describes both the test tools and the methods used to quickly and reliably avoid the causes of errors.
especially complex, since the parameters of the diagnostic
Test functions in the Test Automation Editor can be used
requests must be set, and the response parameters must
intuitively, and CANoe automatically selects the correct
be checked for each test. However, this situation can be
OEM-specific diagnostic services. Automatic selection
considerably simplified by having the tester use an abstract
makes the test sequences easier to reuse for other ECUs,
perspective. This fully hides routine activities for setting,
and they are easier to create overall. This lets users work
checking and finding error entries from the user.
very effectively, since they can focus on the actual goals of
It would be ideal, if – after stimulation (Figure 1) of a situa-
testing.
tion logged in the fault memory – a test function were
Figure 2 illustrates the method for accessing the fault
available that could hide all UDS-specific aspects and
memory. During execution, the ECU’s fault memory is
automatically check the diagnostic responses. Such a funcThe importance of good diagnostic functions for successful
Functional Principle of Fault Memory
vehicles is illustrated by countless reports of vehicle defects
Based on the widely used Unified Diagnostic Service (UDS)
that required multiple repair attempts until they were
standard ISO 14229 [1], this article explains which data is
finally corrected. This causes unnecessary aggravation and
provided for fault diagnostics. A central element of the
costs, and it is damaging to the manufacturer’s image.
UDS standard is 24-bit trouble codes. Most of the trouble
Therefore, the motto must be: “If there is a defect, it must
codes identify OEM-specific error causes such as “Battery
be corrected quickly and accurately.”
voltage – voltage too low.” In addition, the standard de-
The fault memory logs irregularities before they finally lead
fines certain trouble code groups such as “Drivetrain.”
to component failure. With regular vehicle maintenance in
For each trouble code, an 8-bit status mask indicates
a service department, defects can be detected and cor-
whether the error occurred and when, such as “Test not
rected before undesirable effects make their appearance.
passed since current power up.” Even more supplemental
Diagnostic functions are also important during product
details can be stored as optional environmental data. This
development, because error states naturally occur more
data is OEM-specific and it records other helpful measure-
frequently during testing and trial phases. Relevant data
ment data, such as the number of error events and at
from the vehicle makes it easier to perform diagnostics,
which odometer reading the error was observed for the
possibly without even requiring any additional test instru-
first time and most recently.
ments. Therefore, it is important to correctly log error
During vehicle operation, each ECU collects the error states
states in fault memory.
that have occurred in its fault memory. With suitable tools, you can use diagnostic services to access this memory. Typical requests are:
3/38
tion might do the following: “Read the environmental data
Figure 1: Left: Testing fault memory in the development phase – Right: Fault memory being used for vehicle diagnostics during everyday vehicle operation.
Figure 2: Testing fault memory with the Test Automation Editor
3/39
polled by entering the desired “DTC status mask”. In the response, which might contain many different trouble codes in any sequence, a check is made of whether the trouble code P000004 was reported. If this trouble code is found, the status bit “Failed since last clear” must be set. Each trouble code has associated environmental data, as illustrated by the odometer reading in Figure 2, and this is very easy to check. Although this test function controls a complex sequence, it is easy to set its parameters. In a conventional programming language without dedicated fault memory support, however, it would take considerable effort to realize the same functionality. Fault Memory – Not a Riddle Wrapped in an Enigma The primary goal has been, and continues to be, a faultfree and robust vehicle. Vehicle problems can be detected early and corrected using the fault memory. Therefore, correct self-diagnostics with fault memory should be checked with extensive tests starting early in development. This checking can be formulated in an uncomplicated and very efficient way on an intuitive abstraction level using test design and test execution tools. In this way, fault memories can contribute towards early detection of vehicle problems before they lead to vehicle failure in everyday driving. Translation of a German publication in Elektronik automotive, issue 2/2013 Image rights: Vector Informatik GmbH Link: Homepage Vector: www.vector.com Martin Huck studied electrical engineering at the Ruhr-University in Bochum, Germany. He was then employed as a development engineer in the communications industry for a number of years. At Vector, he worked on software development for CANoe’s Test Feature Set until 2012, and he is now a technical trainer.
Siegfried Beeh studied electrical engineering at the University of Stuttgart, Germany. Since 2002, he has been actively working in software development at Vector, and since 2006 he has been responsible for the “Test Tools & Diagnostic Features” group. As Product Manager for Testing Tools, he is responsible for such product components as the CANoe Test Feature Set and the Test Automation Editor.
3/40
Flexible Test Systems for Efficient ECU Testing Figure 1: The VT System is placed between the ECU and the actuators/ sensors for testing.
Functional Testing with Error Simulation at the Developer’s Bench
Functional testing of a vehicle ECU requires testing of the most significant error conditions as well as actual functional-
able value range, electrical properties of the components
The PC with CANoe is connected via the computer’s
– such as internal resistance or current consumption –
Ethernet port using the real-time capable EtherCAT protocol.
do not conform to specification >>Incorrect input values, especially incorrect sensor data:
This means that flexible test systems can be constructed with minimal integration and wiring effort.
ity in the vehicle. Systems used for this type of testing must fulfill stringent testing requirements. Vector’s VT System is
From the ECU’s perspective the sensor is working
Different modules are available for driving the various ECU
a modular test system tailored specifically to meet the needs of the passenger, commercial and agricultural vehicle in-
properly and measured values lie within the allowable
inputs and outputs. However, all modules share these prop-
dustries. It allows the engineer to perform effective functional testing during the early development phases of the vehicle.
range. However, they are implausible or contradict other
erties: >>The ECU’s I/O lines are connected directly to the
sensor values.
VT System. Each module provides all circuits for the I/O The complexity of electronic and software systems installed
In many cases, ECUs automatically check sensors and actua-
The ECU must react in a defined way in these cases and
channel, thus substantially simplifying the test bench
in today‘s automobiles requires comprehensive testing in the
tors so it is imperative that they are connected during the test.
generate appropriate diagnostic entries. In turn, these en-
setup (Figure 3).
developmental phases of the ECU. Generally, errors detect-
If these external components are missing, the ECU will gener-
tries can be checked by the test system – in this case over
ed early on are easier and cheaper to correct than errors
ate faults or deactivate certain functions. As a result, real ac-
the diagnostic interface.
found in the later phases of development. In this process,
tuators and sensors are usually connected to the ECU for test-
ECUs are rigorously tested individually in functional tests
ing. An alternative would be to simulate the loads and sensors.
Compact Test Systems with the VT System
with special attention given to the numerous error cases.
The great advantage of sensor and actuator simulation lies in
Systems based on CANoe and the VT System demonstrate
Faulty behavior detected in rare cases or in situations that
the potential for automating test flows with suitable models,
that the stringent requirements of high-performance test
are impossible to reproduce in normal operation represent
a Hardware-In-The-Loop (HIL) test is also possible.
systems – with regard to their interfaces and test hardware, test automation, user control of software interfaces
a tremendous problem for manufacturers if those errors ECU Testing in Error Situations
and options for rest-of-bus simulation – can also be imple-
Additional devices are necessary to simulate error condi-
mented in a compact test system for the bench.
Functional Testing of ECUs
tions during an ECU test; like the VT System from Vector.
With CANoe, the user gets a mature and widely used tool
To test its functionality, the ECU is stimulated via its hard-
They are inserted in the circuit between the ECU pin and
for analysis, simulation and test automation. Vector hard-
ware and software interfaces and its reactions are evalu-
the sensors and/or actuators to which it is connected
ware interfaces provide reliable bus interfaces to CAN, LIN,
ated. It is important to present the ECU with a test envi-
(Figure 1). Specifically, these test components enable test-
FlexRay and MOST. External measurement and test hard-
ronment that matches the environment in the real vehicle
ware from various manufacturers may also be connected
as closely as possible. This can be accomplished in a number
ing of the following error conditions: >>Damage to the electrical wiring: Line breaks, short
of different ways. What is most important here is that the
circuits to ground or battery voltage, short circuits
The VT System is a modular I/O system that controls the
ECU should not be able to perceive any difference between
between connection lines >>Sensors or actuators are damaged: Sensors do not
ECU’s inputs and outputs for functional testing with
are not discovered before the ECU has reached the field.
the simulated environment on the test bench and the ac tual environment in the vehicle.
3/42
output any values, the values lie outside of the accept-
via GPIB, the serial port or Ethernet.
CANoe. It allows users to set up compact test benches of widely varying complexity (Figure 2).
Figure 2: VT System modules enable setup of very compact test systems as well.
3/43
Flexible Test Systems for Efficient ECU Testing
lyze the power consumption of different software variants. The module also generates control voltages for external power supplies thus allowing simulation of defined disturbances on the power supply lines. Rated for continuous currents of up to 70 A, the VT7001 can also supply ECUs with high power consumptions. An ECU’s two supply current inputs, Terminal 15 and Terminal 30, can be controlled separately. Furthermore, there are modules for bus connections, for Figure 3: Modules of the VT System integrate all of the I/O channels needed for the test.
the execution of simulation and test in real time on the VT hardware as well as for the integration of custom I/O circuits in the VT System. Other modules are in development. The ECU’s I/O channels do not need to share these test setups in all cases, since the VT modules are provided separately for each channel. This simplifies test automation and programming and facilitates clear representation of multiple errors and more complex user operations.
>>If necessary, real sensors and actuators can be
duced with high precision. The module can also generate
Based on its modular organization, the VT System is ideally
connected to the module. Using relays on the VT module,
PWM signals and simulate a potentiometer on a channel
suited for both small test setups at the developer’s bench
users can toggle between the use of externally
how it is used for fuel level sensors, for example.
and comprehensive test benches in the test laboratory.
connected original equipment components and the
The VT2516 digital module controls ECU inputs or outputs
Together with CANoe, the test engineer has a flexible and
simulation residing in the module. >>On each ECU pin, relays can be used to generate errors
that utilize digital signals, e.g. lines in the vehicle that are
high-performance solution for automotive compact test
connected to switches, encoding jumpers, small indicator
systems. Test automation is implemented in an efficient
such as line break and short circuits between lines, to
lamps or LEDs. ECU inputs are stimulated by digital signals
and seamlessly integrated package using CANoe and VT
ground or to supply voltage. >>All modules and measurement devices are designed for
with configurable levels; besides bit sequences stored on
System.
the module, PWM signals may also be output here. In the
voltages and currents typically used in vehicle elec-
opposite direction, the module can measure digital or PWM
Translation of a German publication in Elektronik Praxis,
tronics. Additional signal conditioning hardware is not
signals and voltages output by the ECU at each channel.
Special Edition ‘Automotive’, issue September 2011
required. >>VT System modules are automatically registered onto
Using selectable resistors, loads can be simulated or pullup or pull-down circuits implemented.
Image rights:
CANoe and are ready for use after a minimal configura-
An ECU’s power supply lines are connected to a power
Vector Informatik GmbH
tion effort. All measurement, output and control signals
source through the VT7001 module (Figure 4). Precise cur-
can be accessed through CANoe and may be used in test
rent measurements are acquired over a wide range making
Links:
scripts together with bus signals, or evaluated in analysis
it possible to check quiescent states, for example, or ana-
Homepage Vector: www.vector.com
windows.
Product information VT System: www.vector.com/vt-system Product information CANoe: www.vector.com/canoe
The VT1004 load and measurement module is connected to Stefan Krauß studied Computer Science at the University of Stuttgart from 1990 to 1995. After graduating, he worked as a scientific assistant in the Software Engineering department of the university’s Institute for Computer Science until 2001. Since 2002, he has been employed at Vector Informatik GmbH in Stuttgart where he is currently Product Manager for the VT System.
the outputs of an ECU. In the vehicle, these outputs are normally connected to actuators such as positioning motors and lamps. The module contains an electronic load for each channel to simulate these actuators. The voltage at the ECU output is measured at a sampling rate of 250 kSample/s; it is then processed in the module and the results are transmitted to CANoe as momentary, mean and effective values. The module can also measure PWM signal parameters. It can handle high continuous load currents of up to 16 A, such as those occurring when lamps and motors are driven. The VT2004 stimulation module is connected to the inputs of an ECU. To simulate sensors, it has a decade resistor on each channel that can be controlled by a test script. Alternatively, the sensor can be stimulated by voltages; voltage curves or sequences stored on the module can be repro-
3/44
Figure 4: The new VT7001 module supplies an ECU‘s power supply inputs.
3/45
is actually received. Other messages, on the other hand,
The central gateway of the Panamera routes more than
should be routed as quickly as possible and one-to-one
3,000 different CAN signals over the six CAN buses in frac-
without multiplication or suppression. For this purpose, a
tions of a second; in the process, it must consider 25 differ-
routing rule is stored in the gateway for each message to
ent transmit types. The time consuming manual error de-
be routed. These rules contain information on the source
bugging in test vehicles led Porsche developers to seek a
and target networks and the copying rule.
more efficient method of evaluating vehicle network traces
Integration of gateway ECUs in the vehicle is the responsi-
in developing the Panamera. Key requirements for the new
bility of the automotive OEM. Error-free operation of the
system were that it should be capable of verifying the
gateway is a key prerequisite to ensuring that the networks
gateway data traffic during real test drives and in real-
and ECUs work together properly. In verifying routing be-
time. However, after initial market inquiries with tool pro-
havior, it is absolutely essential to run numerous tests in
ducers and test specialists it became apparent that a suit-
different driving situations and conduct a detailed analysis.
able tool or test system was neither available nor known.
Until now, the focus of laboratory tests was to sequentially check all of the gateway’s routing rules by stimulation of
Porsche Echtzeit (‘Real-Time’) Trace Analyser
the input signals. On the output bus, the expected results
A solution was created in collaboration with specialists
were checked against routing algorithms. At Porsche, these
from Vector, whose effort led to a tool known as the
tests are also performed under different physical condi-
“Porsche Echtzeit (‘real-time’) TRace Analyser (PETRA).
tions such as under-voltage and over-voltage as well as
The testing and simulation software CANoe serves as the
various temperature profiles.
foundation for PETRA. This tool was optimized for ECU tests and it enables – by means of various configurations
Porsche Validates Gateway ECUs Automatically Real-time Analysis in Driving Trials Supplements Laboratory Tests
Limitations of Laboratory Tests
– automatic test sequences including rest-of-bus simula-
Although test data generated in the laboratory with spe-
tions. Furthermore, it offers the ability to r eplay logged
cial test or HIL systems does indeed test basic functional-
network communication and to create detailed test re-
ity, sporadic errors are often only revealed under real stress
ports. To implement automatic test sequences, the Test
scenarios and in the interplay of all bus systems and ECUs.
Feature Set (TFS) contained in CANoe provides test func-
In particular, stress situations under high bus load and the
tions in the Communication Access Programming Lan-
simultaneous occurrence of certain events can lead to
guage (CAPL) script language. CAPL uses a C-like syntax in
complex errors.
On the Panamera, Porsche is implementing the “Porsche Echtzeit (‘real-time’) TRace Analyser” (PETRA) for validation of gateway ECUs. PETRA, which is based on the CANoe test tool, automatically generates gateway tests from routing tables. These tests are used in driving trials, checking the routing functions online. PETRA can be used to conduct analysis later as well, based on recordings of the bus communication as a supplement to the scope of sequential testing in the laboratory. This gives Porsche a test tool for automatically detecting routing errors.
Architecture
way ECU (Figure 1). Gateways interconnect the various
The “Panamera,” available since 2009, is the first produc-
networks in the motor vehicle and provide for fast data ex-
tion vehicle in the history of the sports car manufacturer to
change across networks.
unify a four-door Gran Turismo concept with classic sports
3/46
car design. Engine options range from a 3.6-liter six-cylin-
Intelligent Gateway Functions
der engine to a 4.8-liter eight-cylinder turbo, spanning a
In the motor vehicle, it is important to transfer information
power range from 220 to 368 kW. Depending on the specif-
between networks as quickly and intelligently as possible.
ic model version and options, features may include full-time
One must consider the different bandwidths of the net-
all-wheel drive, dual-clutch gearbox and a model with
work buses. As a rule, a periodic message arriving at the
hybrid drive, which is currently in development.
receiver end of a High-Speed CAN bus every ten millisec-
The electronics architecture of the Panamera is based on
onds cannot be routed by the gateway as quickly as on a
more than 30 CAN ECUs, which are distributed over six
target network with a lower bandwidth. The copying rule
CAN networks. It is supplemented by twelve LIN networks
here could be that the most recent value should only be
with a total of 25 LIN slaves. A MOST bus serves to network
sent every 100 milliseconds on the slower bus. Suppressing
the Infotainment systems. The six CAN buses for diagnos-
messages can reduce the volume of data and adapt it to
tics, convenience systems, HMI (Human Machine Interface),
the lower bus speed. In the reverse case – from slow to fast
powertrain, chassis and crash safety are all connected –
– the gateway may need to repeat the messages in its
with a maximum of two LIN branches – to a central gate-
sending section, i.e. send a message more frequently than it
Figure 1: Layout of the Panamera gateway ECUs with six CAN buses and up to two LIN buses
Figure 2: PETRA is configured easily via a graphic user interface
3/47
Porsche Validates Gateway ECUs Automatically
whether an error occurs continually or only once every 1,000 kilometers, or whether certain cycle time violations are very large or relatively small on average. Summary and Outlook The CANoe tool has been used at Porsche for a long time now. In 2007, the existing tool chain was extended and conFigure 5: PETRA checks for conformance to routing and copying rules and outputs results in a test report.
tinually enhanced with the addition of the “Porsche Echtzeit (‘real-time’) TRace Analyser.” PETRA demands very little training effort for employees. The new automated approach to analyzing the routing of real communication
Figure 3: Only the messages selected in the first column are considered in generation of the test configuration
standalone tool, PETRA lets users create test modules
data ideally supplements the stimulation-based test sce-
without requiring that a CANoe license be installed.
narios of laboratory tests. Engineers at Porsche and Vector Informatik closely worked together in developing the new
Test Report Speaks the Language of the Automotive OEM
gateway validation system. The tool enabled early detec-
formulating tests; CAPL recognizes special functions, which
the cycle times. In addition, the gateway generates and
During the test, the test system creates a detailed report
tion of potential errors during ECU development for the
lets it react to bus-related events such as the receipt of a
sends messages with signals from different Rx messages
on events that occurred. The test report was optimized for
Panamera and attained a high maturity level. The time
message. Tests can be set up and parameterized in XML files
(“combined messages”). For each Rx message, the gener-
Porsche-specific processes and terminology, so that it can
advantage in analyzing communication data is about 65
using predefined test functions and control functions. A com-
ated message contains a so-called “aged bit.” If the gate-
be equally understood by both experts in gateway develop-
percent compared to previous manual debugging. The gen-
plete test run is represented by a test module in CANoe.
way determines that a delay has occurred in incoming peri-
ment and colleagues from other technical departments.
erator approach lends flexibility to the PETRA concept,
PETRA was developed as a contract project by Vector, and
odic messages that exceeds the allowable tolerance, it sets
The checks seamlessly cover all relevant copying rule viola-
which can be applied to future vehicle series and genera-
together with standard functions of the CANoe TFS, it serves
the aged bit before routing the combined message. Active
tions for the specific message type, and they can operate
tions. If necessary, other bus systems such as FlexRay or
to validate the CAN gateway functions of the central Pana-
aged bits indicate to the receiving ECUs that the informa-
on either the byte or signal level, depending on the situation.
Ethernet could also be integrated in the PETRA concept.
mera gateway ECU (Figure 2). It generates the entire CANoe
tional content of the combined message has limited validity.
For road tests, the system can be configured so that when
test module components needed to validate a gateway revi-
The user can use PETRA to take information from the rout-
an error occurs, a relevant message immediately appears
Translation of a German publication in ATZ elektronik, issue
sion level; these components can be used both during test
ing table and automatically generate an extended configu-
on the screen. This enables immediate repetition any rout-
6/2010
drives as well as offline in the evaluation of data recordings.
ration table, also in Excel format. The test engineer then
ing errors resulting from operating and driving maneuvers.
Routing and copying rules for the messages of multiple buses
uses this to select the messages to be analyzed in the gate-
In offline tests, log files recorded during the test drives are
Image rights:
can be evaluated simultaneously here so that they could
way data traffic (Figure 3). If a routing relationship is
played back in CANoe via Replay blocks. One helpful debug-
Porsche: initial figure, 2, 3, 5
focus on specific messages in individual tests. Porsche engi-
selected in the first column, the test generator considers
ging feature is the ability to jump directly to the point in the
Vector Informatik GmbH: figure 1, 4, 6
neers insisted on wide-ranging filter options right from the
this line in creating the test configurations. All other mes-
trace data at which an error has occurred. Frequently,
start. The gateway developers expressly wanted a system
sages are ignored in this test. Furthermore, various evalua-
events occurring before and after the error yield useful in-
Links:
that could check the totality of all messages and be able to
tion limits may be specified, for example tolerances for
formation on the cause of the error. Error statistics provide
Homepage Porsche: www.porsche.com
analyze individual routing relationships with a simple config-
cycle time monitoring and the allowable gateway time for
important indicators on the frequency of errors and “error
Homepage Vector: www.vector.com
uration. In particular, developers wanted to intentionally fil-
BAF and BÄS messages. PETRA then automatically creates
quality.” For example, it might answer questions about
Product Information CANoe: www.vector.com/canoe
ter out the special data traffic that result in exceptional situ-
all of the files needed to execute a test run (Figure 4). Ex-
ations, for example: in starting the vehicle, shutting down the
amples include an XML test module with a CAPL test
network, since most test systems generate a massive num-
library as well as a CAPL filter that might be used upstream
ber of irrelevant error messages in these cases.
of the Trace Window in the CANoe Measurement Setup.
Karl-Peter Spring (Dipl.-Ing. (FH) studied Industrial Automation Engineering at the Polytechnical College at Reutlingen. In 1999, he joined the Dr. Ing. h. c. F. Porsche AG company, where he is area leader for all central gateway ECUs in the “Networking, Diagnostics and Gateways” department.
The CAPL pass filter only passes those messages that are Suitable for Both Online and Offline Tests
needed for the generated monitoring tasks. This covers the
A routing table in Excel format describes all signals and
basic requirements for a CANoe test run (Figure 5). As a Thomas Hohmann (Dipl.-Inf.) studied Computer Science at the Technical University at Ilmenau. Since 2007, he has been working at the Dr. Ing. h. c. F. Porsche AG company, where he is involved in gateway development in the “Networking, Diagnostics and Gateways” department.
messages to be routed by the gateway. Each line corresponds to a routing rule and defines the way in which a message should be routed. Messages that are routed in their entirety (1:1) are organized into the following message types: Periodic messages, BÄS messages and BAF messages. BÄS messages (BÄS = immediately on change) are special cases of periodic messages, which the responsible ECU sends in addition to the normal periodic sending as soon as an input value changes – e.g. from a sensor. BAF messages (BAF = on active function) are one-to-one messages that the gateway should route directly and without modifying
3/48
Figure 4: PETRA automatically creates a XML test module and a CAPL test library for test execution.
Figure 6: PETRA checks for conformance to routing and copying rules and outputs results in a test report.
Katja Hahmann (Dipl.-Ing.) studied Electrical Engineering at the Technical University of Chemnitz. In 1997 she joined Vector Informatik GmbH in Stuttgart where she is group leader in CANoe application development for the product line Networks and Distributed Systems.
3/49
Testing
Easy access to CAN network analysis Jochen Neuffer
C
Author Jochen Neuffer Product Management Engineer Vector Informatik GmbH Tools for Network and Distributed Systems Ingersheimer Str. 24 DE-70499 Stuttgart Tel.: +49-711-80670-4808 Fax: +49-711-80670-584808
[email protected] Link www.vector.com
hanging requirements are continually in flux when it comes to networking ECUs (electronic control units). The general trend for tasks is becoming increasingly more complex, and so they require even more complex tools. However, there are often simple tasks whose quick handling is actually hindered by this complexity when the user is confronted with a multitude of features. For such tasks, the user wants an easy-tooperate tool. However, if the task requires it, the user also wants to be able to access an extensive set of features. These conflicting interests occur in typical tasks such as network monitoring, stimulation or data logging. In the case of monitoring, for example, different perspectives are often of interest in observing the data
traffic on the network. Here, the Trace function shows the time sequence of all network events. It is also possible to graphically display individual parameters. Moreover, the user typically wants an overview of the network statistics. In stimulation, on the other hand, specific messages need to be sent on the network either spontaneously or periodically. And of course data needs to be logged for later off-line analysis. These three core tasks are the domains of CANalyzer Beginner, a special execution mode of CANalyzer from Vector Informatik. The mode that focuses on these core tasks is easy to operate even for new users. The individual task areas may be combined, and each may be added or removed whenever the user wishes. The full range of CANalyz-
er features is at first not visible to the user, but it can be called up at any time. CANalyzer Beginner can be immediately used as part of any CANalyzer installation (CAN and LIN networks). This saves the user time and money, because there is no need to purchase or install a separate tool. The Beginner mode exploits the advantages of the revised window layout in CANalyzer. The individual tasks are organized on fixed desktops, which do not need to be modified, and which already contain pre-configured windows (see Figure 1). This eliminates the need for time-consuming manual configuration. Since the windows have fixed positions, it is easy to focus on the essentials. Furthermore, the windows cannot be closed, which eliminates
Figure 1: Desktop with fixed configuration for network monitoring task (Source: Vector Informatik)
3/50
CAN Newsletter 4/2012
Figure 2: Creating a new configuration with CANalyzer Beginner (Source: Vector Informatik) searching for inadvertently closed windows. The windows are configured by drag-and-drop operation or with the help of functions on the toolbar. One can create his own configuration with a few mouse clicks. To do this, the user needs to add for each network a channel and a suitable network description file (DBC for CAN or LDF for LIN) to the central configuration window (see Figure 2). If applicable, the bit-rate is also configured, and the user then selects the tasks that need to be performed. During the measurement, for example, the Trace window offers many different options for filtering specific events, such as blocking and passing filters for messages or channels. Furthermore, the Trace window offers a long data history, so that longterm measurements over several days can be preserved. The Statistics window offers a detailed summary of the current situation
on the network and can prepare statistical information on the node level or the message level. Also complex tasks may be performed. A configuration created with the Beginner mode can be loaded in its full form in CANalyzer. It is also possible to use CANalyzer to perform further off-line analysis of logged data. There is a seamless migration path from CANalyzer Beginner to CANalyzer. Configurations that have been created with CANalyzer Beginner can be loaded in CANoe as well. Future planning for CANalyzer Beginner calls for supporting additional tasks and possibly adopting concepts into CANalyzer.
CAN Newsletter 4/2012
3/51
troubleshooting, the test driver has the option of recording
continual logging. Depending on the configuration of the
audio comments and camera images along with the regu-
ring buffer, logged data may be available for a time period
lar data during the test drive. In parallel, GPS data can be
before the trigger and possibly for a configurable post-trig-
added to the bus communication for geographic reference.
ger time after the trigger occurs. The ring buffer is usually
After logging, the data is typically converted on the PC, so
configured with special software (Figure 2).
that it can be analyzed in other programs such as CANoe,
The special script language Logger Task Language (LTL) can
CANalyzer or CANape.
be used to execute complex logging tasks. This can be illustrated by a simple programming example: Creating a class-
Special Data Loggers for Test Fleets
ing table during logging. First, the symbolic signals Speed
At first glance, it would seem reasonable to use a note-
and Brake from a database are automatically converted to
book-based solution for in-vehicle logging. Using a note-
LTL code. The test engineer only needs to add supplemental
book with a suitable network interface should be able to
code for classing with the CLASSIFY operator:
offer all required capabilities, since logging functionality
can be implemented in software. However, commercially
available notebooks cannot handle the required tempera-
CLASSIFY
ture range and the system must first be booted, which
takes some time – even with fast notebooks. This implies
another requirement for data loggers: short startup times.
In this example, the Variable Speed value is defined in km/h
Data must be acquired quickly enough for the first mes-
over 20 classes, each class has a width of 10 km/h, and
sage on the bus to be logged. All of the noted requirements
0 km/h is set as the start value of the first class. This yields
are fulfilled by special fleet loggers such as devices from
the following class distribution:
VAR Speed = CAN1 DATA 200h [2 3] Brake = CAN1 DATA 100h [3(0)] MyClassify COUNT (Brake) OVER Speed (20 CLASSES OF 10 BASE 0)
Vector’s GL3000/GL4000 logger product line (Figure 1). Their extended temperature range also makes it possible to
Class
Value range [km/h]
clear time references for the acquired data.
1
0 - 9
Acquire Vehicle Data Reliably with Data Loggers
Data Processing To reduce the volume of incoming data, even during the
2
10 - 19
When different bus systems are used in vehicles, the effort required for troubleshooting and analysis always increases.
….
….
19
180 - 189
20
190 - ….
use them under extreme environmental conditions. These special fleet loggers also have a real-time clock, ensuring
Seamless Logging on Test Drives
Laboratory tests are no longer sufficient to simulate real situations for communication in the total vehicle system. Only extensive test drives in the real environment can deliver the necessary testing depth. In test fleets, data loggers installed in the vehicles are the tool of choice for logging the data traffic of all buses and select I/O lines. This makes it possible to access the test drive data at any time in quality assurance tasks.
test drive, these loggers allow users start logging only in response to predefined events. In triggered logging, data is continually written to a ring buffer, so when the trigger event occurs, this ring memory is closed, and the data is saved. Logging is then resumed in a new ring memory. This method substantially reduces data volumes compared to
3/52
Shortly before production maturity, in-depth testing in ve-
it. Since the loggers are often permanently installed in test
hicles is typically conducted in the context of test drives. To
fleet vehicles, and a test series may take several weeks,
achieve the greatest possible test coverage, some of these
they must exhibit very low current draw in their quiescent
tests are conducted under extreme environmental condi-
states – another requirement of data loggers. Further-
tions. Whether they are winter tests in Finland at -30° C,
more, the devices must be ready for operation as quickly as
hot weather tests in Death Valley at over 50° C or week-
possible, so that the first occurring message can be logged
long drives through the Brazilian rainforest at high humidi-
too.
ty and on rough roads, in the end the vehicle and all of its
Not only are the loggers typically permanently installed, of-
components must operate smoothly. The installed data
ten they are mounted at very inaccessible points, e.g. under
loggers must be able to withstand these harsh conditions
a seat or behind a trim panel in the cargo space, and they
as well. This means that they must be mechanically rugged
may be inaccessible because of other instrumentation.
and operate reliably over a broad range of temperatures.
Therefore, it is advantageous if the test engineer can use a
Various bus systems are used in motor vehicles or commer-
UMTS or WLAN wireless connection to read data from a
cial vehicles: CAN, LIN and FlexRay. One technical require-
logger. As an alternative, it should also be possible to read
ment is that the data of all of these buses needs to be
data directly via USB or by swapping out the memory me-
logged simultaneously, i.e. time synchronously. The logger
dium. To permit clear traceability of certain driving situa-
must not influence the bus traffic here; it may only observe
tions to a specific error pattern in later offline analysis and
Figure 1: Special data loggers for in-vehicle use are rugged and have practical and effective interfaces.
3/53
Rugged Data Logger Endures Tough 24h Race Case Study GETRAG
Figure 2: Trigger configuration in the Vector Logger Configurator
The Customer
The Advantages
With a history of producing 2.6 million transmissions, the
A compact device reliably acquires all required bus and
GETRAG Corporate Group is one of the largest transmis-
measured data > All bus data is acquired from the CAN channels. In
sion manufacturers in the world. In 2008, the company successfully launched the GETRAG PowerShift® dual-clutch
addition, the user may choose to have the measured data
transmission on the market, which is installed in such cars
logged over the current CAN protocols CCP or XCP.
as the Mitsubishi Lancer Evolution X.
> Measurement signal lists are individually configurable > The rugged design and strong aluminum housing protect
The Challenge The data of each classing task is saved in text-based results tables that can easily be read into a program such as MS® Excel for post-editing. Summary Currently, there are many different data loggers on the market. However, only fleet loggers are suitable for the harsh operating conditions in the automotive field. Loggers should offer a wide range of features that cover the majority of requirements for today’s vehicles during test drives. They include a large number of CAN, LIN and FlexRay channels, short start-up times and I/O ports on the logger. UMTS, WLAN, USB and Ethernet offer the necessary flexibility to configure the loggers and transfer the logged data. Fleet data loggers from Vector, with their extended temperature range and durable packaging, equip the test engineer with devices ideally suited for use under extreme environmental conditions.
Jochen Neuffer studied Information Technology at the University of Applied Science in Esslingen. Since 2002, he has been working at Vector Informatik where he is a Product Management Engineer in the Tools for Networks and Distributed Systems area.
Reliable acquisition and quick evaluation of measured data
the device when used in challenging environments. > Parallel logging of GPS data
in a challenging car racing application
> Data exchange is simple and fast, even during bus
The objective was to put the GETRAG PowerShift® transmission to the test in a Mitsubishi Lancer Evolution X during the ADAC Zurich 24h car race to evaluate its durability and racing performance. Six different CAN control modules
operation; data is exchanged by SD card with an easy-to-access card slot. > Offline evaluations are possible with any tool, without requiring connection to the data logger.
were used to reliably and quickly log measured data throughout the race for performance analysis. The Solution The rugged GL1000 fleet logger The GL1000 was used as an autonomously operating test instrument, which proved to be rugged, and reliable in processing all trouble-free measured data. This demonstrated that the GL1000 operates flawlessly, even in a tough car racing environment that places especially severe demands on mechanical toughness. Because of its toughness and ease of configuration, the logger fully satisfied all of the requirements placed on it.
Translation of a German publication in Automobil Elektronik, February/2011 Image rights: Vector Informatik GmbH Links:
V2.0 | 2016-05
Homepage Vector: www.vector.com
3/54
www.vector.com/contact
3/55
the CAN 2.0A standard. It contains all diagnostic services
Validation Process and Tool Environment at General
allowed for addressing an ECU’s diagnostic system to ob-
Motors Europe
tain diagnostic information. These services are then output
In development of the Opel Insignia, GME introduced the
by the diagnostic tester to establish diagnostic communi-
DiVa tool from Vector Informatik for the first time. DiVa
cation. As soon as a request is sent, the addressed ECU(s)
automates generation and execution of diagnostic tests.
react with either a positive or negative response: >>Positive responses contain the diagnostic information
Figure 2 shows the tool environments for the Opel Corsa
requested by the diagnostic device. If there is a lot of
tool. While validation is largely performed manually in de-
diagnostic information, the response may include
velopment of the Corsa, in development of the Insignia the
and Opel Insignia. In both cases, CANoe [5] is used as a test
multiple message frames. >>Negative responses contain a clearly defined Negative
vast majority of testing is covered by fully automated tests.
Response Code, which gives information indicating the
an ECU performed by a test engineer at GME. Develop-
reason for the negative response. Negative Response
ment of the ECU software is subdivided into several phases.
Codes are given in accordance with the GM Diagnostic
At the beginning of an ECU development, the focus is more
Specification.
on implementation of ECU functionality than on diagnostic
Figure 3 shows a typical diagnostic validation process for
services. The latter are then elaborated and developed in
Automatic Validation of Diagnostic Services by Use of a Diagnostic Integration and Validation Assistant at Opel For the first time, a fully automated test case generator has been introduced in diagnostics validation at General Motors
The received responses must enable technicians to deter-
subsequent software versions. As shown in Figure 3, with
mine the cause for a fault, so that they can perform the
introduction of the Phase 1 (SWR 1) software version, only
right tasks to solve the problem.
a small number of diagnostic services are implemented.
Therefore, the success of a fault correction in the service
The use of diagnostic software components at GME (CAN-
garage depends considerably on the accuracy and precision
desc) has made it possible to implement a portion of the
of the data output by the diagnostic system. Proper imple-
diagnostic content early at the start of development, and
mentation of diagnostic services is essential in performing
as a result it is integrated in the ECU earlier (Figure 3).
quick and professional service or maintenance to the satis-
The number of diagnostic functions to be tested grows
faction of customers. Diagnostics also plays an important
with each development cycle. Once all diagnostic services
role in end-of-line testing: it is used to program ECUs and
have been implemented, regression tests are performed
assure product quality. That is why comprehensive valida-
(SWR 7). If no more faults are reported in diagnostic ser-
tion of diagnostic functionality is absolutely necessary.
vices at that development stage, the ECU is production mature in the execution of diagnostic services.
Europe (GME) Development. This article describes the introduction of this automated testing of diagnostic implementations based on the example of the new Opel Insignia. An electronically readable diagnostic specification forms the basis for test generation. The article describes how the tool used – CANoe.DiVa (Diagnostic Integration and Validation Assistant) from Vector Informatik – was integrated in the existing tool environment, and it addresses cost and time savings as well as improvements to technical processes that were realized compared to conventional, manual validation at the Opel Corsa.
4/0
Introduction
functionality provided by the ECU, it is crucial that diagnos-
One consequence of strong competition in the global auto-
tic services are correct. They transport information that
motive market is that it is forcing a shortening of develop-
helps mechanics in the service garage to quickly determine
ment cycles. Another is that the complexity of the electronic
the cause of a fault and correct it. This information must
networking architecture is continually increasing. Key goals
make it possible for the mechanic to decide which compo-
in replacing conventional systems by electronically con-
nent is the source of the problem and what needs to be
trolled systems relate to cost reductions, a high level of
replaced to restore full operational readiness. If this is not
safety and reliability as well as better manageability. De-
assured, the result may be erroneous replacement of prop-
spite all of the benefits, it must not be forgotten that in-
erly operating units [1], which causes a rise in warranty
creased numbers of electronic components in vehicles can
costs and a decline in customer satisfaction.
increase the probability of electronics-related faults. Since
The E/E architecture of the Opel Insignia consists of sever-
reliability is an important criterion for customers when pur-
al Controller Area Network (CAN) and Local Interconnect
chasing a new vehicle, it is essential to introduce new meth-
Network (LIN) bus systems [2, 3]. All bus systems are ac-
ods that enable mastery of this complexity, accelerate the
cessed via a central diagnostic port (DLC), see Figure 1.
development process and guarantee proper operation of
Communication is defined by a GM-specific protocol. This
the installed ECUs. Particularly in the area of diagnostic
GM diagnostic specification is based on KWP2000 [4] and
Figure 1: E/E architecture and diagnostic communication on the Opel Insignia
4/1
Automatic Validation of Diagnostic Services by Use of a Diagnostic Integration and Validation Assistant at Opel
Since a test engineer normally tests a number of different
in the existing and established GME tool chain. Test cases
ECUs simultaneously, without adequate tool support it is
for checking the individual services are automatically de-
impossible for the engineer to perform the large number of
rived from the CANdela diagnostic specification (CDD file).
tests necessary to cover all of the implemented diagnostic
The generated code is based on the CANoe programming
services of the individual software versions. As a result, only
language CAPL (Communication Access Programming
newly implemented diagnostic services are tested in-depth,
Language) and can therefore be examined at any time. If
and test engineers perform representative regression tests
problems occur, the test engineer can intervene in the auto-
for previously integrated individual services based on their
mated test sequence and troubleshoot their causes (trans-
experience. By using a suitable automation tool, more tests
parency). Furthermore, CANoe’s logging functions enable
may be performed in validation while simultaneously re-
traceability and evaluation of the diagnostic data flow on
ducing effort.
the CAN communication level.
Table 1: Test execution times for Opel Insignia ECUs
The following steps are necessary to conduct a test with
test module in order to test all diagnostic services support-
Test Coverage
DiVa: >>Select the ECU and its variant
ed by the ECU. To assure conformity to the GM diagnostic
Automating the tests extends test coverage and simulta-
specification, the DiVa extension maps the test procedures
neously shortens the time needed for test execution. The
the following requirements: >>Seamless integration in the existing tool chain
>>Configure the test
of the GM standard. The test generation process produces
extent to which DiVa covers the test procedures described
>>Generate the test
a detailed description of the generated test cases, CAPL
in the GM Diagnostic Specification is described below. The
>>Transparency and reproducibility: The test engineer must
>>Add the generated test module to the CANoe test
test codes for the CANoe test module and the associated
quality and number of generated test cases depend in large
be able to track the executed tests and repeat them. >>Conformity to existing testing methods at General
nvironment e >>Execute the tests
CANoe test environment.
part on the completeness of the machine-readable diag-
>>Evaluate the test report
Test execution and Report Evaluation
rived from it.
After the test has been generated, the user opens the gen-
A total of about 350 test sequences are defined in the GM
The user can modify test constraints in DiVa at any time.
erated test environment in CANoe and starts the test. The
Diagnostic Specification. The test sequences cover both
Diagnostic Services of the ECUs. >>Expandability by the test engineer
Among other things, the “Intensity” parameter is used to
test duration depends on the complexity of the diagnostic
“good case” and “bad case” tests. A large share (approx.
configure the test contents, e.g. “full test”, “quick test” or
specification and the user-defined test scope that is select-
80 %) of the test procedures are covered by fully automat-
>>Automatic generation of test cases: The specification
“good case test”. In addition, under “Supported services”
ed, and it may vary from just a few minutes to several hours
ed tests in DiVa. An application-specific user input is re-
the user can exclude certain services from the test or mod-
(Table 1). At General Motors, the CANoe test environment
quired for 45 (15 %) of the test procedures defined in the
ify data contents of the services under “Data customiza-
serves as a joint platform for test automation and simpli-
GM Diagnostic Specification. In such cases, DiVa pauses
tion” (see Figure 4).
fies reuse of existing GM test programs. For example, end-
test execution and asks the user to put the ECU in the re-
In updating the diagnostic specification, i.e. the CDD file,
of-line flash test procedures are also programmed in the
quired state. The remaining 5% of test procedures are not
As shown in Figure 2, DiVa represents the link between
DiVa enables synchronization to the new specification
CANoe programming language CAPL. To simplify analysis
supported by DiVa and must be tested either manually or
CANdelaStudio (diagnostic specification) and the proven
while preserving previously defined settings. From a techni-
by the test engineer, test reports are structured according
by other means. This includes tests that would put the rest
validation tool (CANoe). DiVa can be seamlessly integrated
cal perspective, DiVa generates CAPL code for the CANoe
to the GM diagnostic specification. Figure 5 shows a typical
of the test procedure at risk (e.g. generate EEPROM errors
test report.
and detect them) or would cause long-term changes to the
Requirements for the Validation Tool A tool for automated diagnostic validation must satisfy
Motors: The tool must support existing test methods. In
nostic specification (CDD file). All generated tests are de-
the diagnostic area, the GM Diagnostic Specification already defines mandatory test procedures for GMLAN
must exist in a machine-readable format to enable this. From Specification to Test Execution and Report
Evaluation
ECU (e.g. an ECU without calibration data).
Figure 2: Comparison of diagnostic validation and tool environment on the Opel Corsa and Opel Insignia
4/2
Figure 3: Scope of diagnostic functions in various phases of ECU development at GME
4/3
Automatic Validation of Diagnostic Services by Use of a Diagnostic Integration and Validation Assistant at Opel
Testing depth is further enhanced by including execution of
on the Opel Corsa and automated testing on the Opel
additional non-GM-specific test cases.
Insignia.
Comparisons made at GME between validation for the
By using DiVa, execution and evaluation times were short-
Opel Corsa and for the Insignia conclude that DiVa short-
ened considerably on the Opel Insignia compared to the
ens test execution time enormously by predominantly auto-
Corsa. In the studied case, 3- to 5-fold improvement was
mated execution of all generated test cases, Figure 6.
attained (Figure 6). In particular, the time savings was
Table 1 shows a summary of execution times and the num-
enormous for ECUs with a large number of diagnostic ser-
ber of generated test cases for ECUs in the Opel Insignia.
vices. If one considers later development phases such as
Often, manual tests can only be performed sporadically
SWR 6 or SWR 7, the time needed for evaluating test re-
due to time demands. Therefore, test results largely de-
sults is reduced even further. This can be traced back to the
pend on the experience of the test engineer and the amount
smaller number of failed test cases in the more mature im-
of time available. At GME, DiVa enables both complete
plementation. This trend continues in each new phase up to
testing of ECUs per diagnostic specifications and greater
the production launch. The production ready ECU must not
test coverage in all development stages.
exhibit any defects; consequently, the evaluation time is equal to the execution time. In this stage of Opel Insignia
Economic Aspects and Efficiency Increases
development, depending on the complexity of the ECU, ef-
When a tool is introduced, its economic benefit is a primary
ficiency might be increased by a factor of 20–40.
consideration. The new Opel Corsa is very successful on the
The cost of the new solution is low, since all that is needed
market, and there are no negative reports of diagnostical-
are licenses for DiVa. A user at GME who is familiar with
ly-related electronic problems. That is why the manually
CANoe can perform DiVa tests – without prior training.
performed validation process on the Opel Corsa was se-
Additional hardware is not required for test execution,
lected as a reference project. In contrast, on the new Opel
since DiVa utilizes the available CAN infrastructure via
Insignia, DiVa was being used as the primary tool for vali-
CANoe.
dation of diagnostic services. It was used to automate a large share of validation tests for the first time. For com-
Limitations on Automatic of Test Case Generation and
parison purposes, the study evaluated the time required for
Test Execution
test execution and evaluation in the validation phase,
Even if automated tools are better than manual test strat-
based on representative ECUs. The values given are based
egies in terms of test scope and time effort, automatic test
on implementation level SWR 5, Figure 3. Most services
generation does run into limitations: >>Quality of the specification: Since the specification
have already been implemented at that point, and a large number of failed test cases had already been captured.
represents the basis for generating test cases,
Figure 6 shows validation effort in hours for manual testing
completeness and accuracy of the specifications are
Figure 4: Setting test constraints in DiVa (here: configuration of services)
4/4
Figure 5: Automatically generated test report in DiVa
Figure 6: Test effort per ECU on the Opel Corsa with manual validation, compared to auto mated validation of diagnostic services on the Opel Insignia (execution and evaluation time)
4/5
essential, i.e. a test is only as good as its specification. Furthermore, there must be conformity to the requirements of the General Motors diagnostic infrastructure (GGSE-I) [6] >>Reproducibility: Due to the non-deterministic properties of CAN communication in a vehicle, certain error situations are very difficult to reproduce in testing. >>Secondary fault: In case of error, the automated test tool – in contrast to a test engineer – cannot distinguish between an initial fault and a secondary fault. >>User interaction: In application-specific tests it may be necessary to put the ECU in a state where additional hardware is necessary. These cases cannot be handled fully automatically in the approach described. Summary
Dr. Philipp Peti studied Computer Science at the Vienna University of Technology. He earned his doctorate degree in Computer Science, also at TU Vienna. Dr. Peti is a development engineer in the “Global Systems Engineering” group at General Motors Europe, located in Rüsselsheim, Germany.
Armin Timmerberg studied Electrical Engineering at the University of Applied Sciences at Wiesbaden. After his studies, he was first employed as a systems engineer in the aftersales area at General Motors Europe. His primary job was to implement ECU diagnostics in the GM Service Tester TECH2. Since 2004, Mr. Timmerberg has been working as a development engineer in the “Global Systems Engineering” group at General Motors Europe, where he is responsible for diagnostic validation. Simon Müller studied Software Technology at the University of Stuttgart. As a product manager he is responsible for CANoe.DiVa on the Vehicle Diagnostics product line division at Vector Informatik GmbH in Stuttgart.
Without the use of test automation tools, it is hardly possible to achieve the desired coverage in validation of the diagnostic functionality of modern vehicles any longer. CANoe.DiVa from Vector Informatik has been adapted to GM requirements to support all established test processes,
Thomas Pfeffer studied Electrical Engineering at the Darmstadt University of Technology. Mr. Pfeffer is group manager for Diagnostics and Test Automation in the “Global Systems Engineering” group at General Motors Europe, located in Rüsselsheim, Germany.
and it fits seamlessly in General Motors Europe’s existing tool chain. It is used as an automated test tool for validation of diagnostic services on the new Opel Insignia. With DiVa, GME is not only shortening test duration, but is simultaneously increasing intensity of testing by its ability
Christoph Rätz is the Director of the Diagnostics product line at the company Vector Informatik GmbH in Stuttgart.
to perform regression tests more frequently. Furthermore, the scope of test coverage is extended by executing additional non-GM-specific test cases. In direct comparison to manual validation on prior successful projects, both technical and economical efficiency have been increased significantly. Depending on the development phase and quality of
Remote Diagnostics
implementation, efficiency increases by a factor of 4 to 20 are realistic. At the same time, it is possible to satisfy the high expectations of customers in terms of quality. Literature references: [1] Thomas, D.; Ayers, K.; Pecht, M.: The “trouble not
Diagnose Vehicles Worldwide!
identified” phenomenon in automotive electronics. In: Microelectronics reliability, Vol. 42, P. 641-651, 2002 [2] LIN Consortium: LIN Specification Package Revision 2.1, OV. 2006 [3] Robert Bosch GmbH: CAN-Spezifikation 2.0, 1991
You are looking for a remote diagnostics solution that lets you access vehicles directly and interactively world-
[4] International Organization for Standardization:
wide? With Indigo Remote you identify systematically the cause of a problem on test drives, at production or in
Keyword Protocol 2000, ISO 14230, 1999
the service shop despite being very far from the site.
[5] Krauss, S.: Testing with CANoe, Application Note [6] General Motors. GGSE ECU Diagnostic Infrastructure
The advantages of Indigo Remote: > Worldwide remote diagnostics, available at any time
> Fast data transfer and very short reaction times
Requirements, Version 1.07, 2007
> Quick and easy setup
> Comprehensive access through hardware interfaces
AN-IND-1-002. Vector Informatik, 2005
> Best data security: Diagnostic data, processes and
— even from third-party interfaces (PassThru API)
security algorithms are not needed on site, so they are not transmitted
More information: www.vector.com/indigoremote
Remote diagnostics with Indigo Remote quickly gives you an expert opinion and shortens diagnostic and repair times. This reduces costs and increases customer satisfaction.
4/6
Vector Informatik GmbH | Stuttgart · Braunschweig · Hamburg · Karlsruhe · München · Regensburg | www.vector.com
Functional orientation is increasingly gaining in significance
implements the Virtual Function Bus for a specific ECU.
in electronic development. AUTOSAR standardizes the de-
The basic software is developed as a component kit and is
scription of individual component or vehicle functions and
commercially available (off-the-shelf software). It contains
the description of the overall system in what is known as
fundamental system functions and abstracts the function-
the System Configuration Description. The methodology
al software from the hardware. It is subdivided into three
for distributing vehicle functions to ECUs is also standard-
areas (Figure 2): >>The Service Layer provides basic services for the func-
ized. As a result, developed functions can be reused in other vehicle projects without changes. The example in Figure 1 illustrates this: The Lighting vehicle function from the Function Library is subdivided into three subfunctions. In vehicle A, the subfunctions are distributed to two network ECUs, while in vehicle B they are distributed
tional software and other basic software modules. >>The ECU Abstraction Layer abstracts higher layers from the ECU hardware >>The Microcontroller Abstraction Layer abstracts higher layers from the specific microcontroller device
unchanged to three ECUs. The communication between the subfunctions is defined in the System Configuration
The ECU Configuration Description is used to configure the
Description.
basic software and the RTE. Initially, this configuration is
In AUTOSAR, there is an ECU Extract of the System Con-
generated from the ECU Extract of the System Configura-
figuration for each ECU that covers the system content
tion Description (e.g. communication over the network).
relevant to the ECU – and often also relevant to a supplier.
The ECU Configuration Description plays a central role for
The elementary components of AUTOSAR architecture for
the behavior of the entire ECU software and is extended
ECU software are: >>Functional software (SWC)
and adapted, step by step, over the course of further development.
>>Run-Time environment (RTE) >>Basic software (BSW)
Diagnostics with AUTOSAR The diagnostic software in AUTOSAR consists of three
The Standard Mix does it: Diagnostics with AUTOSAR and ODX – Part 1: Diagnostics with AUTOSAR AUTOSAR is the future-oriented reference architecture for ECU software. Clearly specified interfaces, standardized behavior and XML-based data formats are the key features of this standard. In AUTOSAR, diagnostics is handled in the modules DCM (communications) and DEM (fault memory). This article first addresses diagnostics in AUTOSAR and related data formats. Description data in ODX format (Open Diagnostic Data Exchange) represents an alternative to
The high level of reusability of the functional software is
modules: DCM, DEM and FIM. The DCM (Diagnostic Com-
due to the abstraction of communication by the Virtual
munication Manager) implements the diagnostic commu-
Function Bus (VFB). The application can be developed and
nication per ISO 14229-1 (UDS) and SAE J1979 (OBDII). All
tested without knowledge of the underlying communica-
diagnostic requests are first preprocessed by the DCM.
tion mechanisms. It does not matter here whether commu-
One of the tasks of the DCM is comprehensive handling of
nication occurs within the ECU or over a network (CAN,
invalid diagnostic requests. The DCM can already fully pro-
FlexRay, etc.). The Run-Time-Environment (RTE) serves as
cess a majority of valid requests; it routes other requests to
the runtime environment for the functional software, and it
the functional software. Each AUTOSAR release has in-
configuring the diagnostic software. Part 2 will address the topic of “ODX in the AUTOSAR development process”.
Standardization is very much the trend in the development
>>Standardized data exchange formats between OEM and
of automotive electronics. The use of open architectures
suppliers >>Definition of a harmonized methodology for developing
and configurable components are intended to let developpects of the development process. In addition, standard-
software >>Support of model-based functional development
ization is intended to be a central measure that contributes
>>Scalability over all ECU and vehicle classes
towards reducing costs. In the past, automotive ECU soft-
>>Considers safety requirements per ISO 26262
ers focus more on the innovative and differentiating as-
Vehicle B
Hardware Topology Functional Library Lighting
Software Configuration
Seat Heating
ware architectures were not standardized. For the supplier,
4/8
Vehicle A
this resulted in different, OEM-specific software architec-
Today, AUTOSAR is the reference architecture for ECU
tures that required different development processes, de-
software. The first production launches with complete AU-
velopment tools and data exchange formats. AUTOSAR
TOSAR software will occur in the near future. The number
(AUTomotive Open System ARchitecture) has the stated
of development projects utilizing AUTOSAR methodology is
goal of standardizing a common, open automotive soft-
continually growing.
ware architecture. The primary goals of the AUTOSAR ar-
The AUTOSAR Consortium is currently working on versions
chitecture are: >>Hardware abstraction
3.2 and 4.x. Versions 2.x, 3.x and 4.0, which were released
>>Clearly specified interfaces
menting vehicle projects. Today, most vehicle producers
>>Standardized behavior of the basic software
work to versions 3.x.
prior to this, have already been used as a basis for imple-
Air Conditioning Distributed System
ECU Extract of System Description
Figure 1: Functional distribution in AUTOSAR
4/9
The Standard Mix does it:
Translation of a German publication in Hanser Automotive, 10/2011
Application AUTOSAR Runtime Environment System Services
Memory Services
Comm. Services
Onboard Memory Comm. Device Hardware Hardware Abstraction Abstraction Abstraction Microcontroller Drivers
Literature: [1] AUTOSAR specifications: www.autosar.org
I/O Signal Interface
[2] Pascale Morizur, Matthias Wernicke, Justus Maier: Neue Wege zur Steuergeräte-Software Teil 1, Elektronik automotive 11.2009
Complex Device Drivers
[3] Pascale Morizur, Matthias Wernicke, Justus Maier: Neue Wege zur Steuergeräte-Software Teil 2, Elektronik automotive 12.2009
Memory Drivers
Comm. Drivers
[4] ISO 14229: Road vehicles – Unified diagnostic services
I/O Drivers
(UDS) [5] ISO 26262: Road vehicles – Functional safety
Microcontroller Microcontroller Abstraction Layer
[6] ISO 22901: Road vehicles – Open diagnostic data exchange (ODX)
Service Layer
ECU Abstraction Layer
Figure 2: Structure of the basic software (BSW)
[7] Klaus Beiter, Oliver Garnatz, Christoph Rätz: Gesetz liche On-Board-Diagnose und ODX, Diagnose in mechatronischen Fahrzeugsystemen III S. 44 ff., Expert-Verlag
creased the functional range of the DCM, while continually
>>Organize snapshot data (freeze frame)
decreasing the remaining diagnostic content of the func-
>>Administer extended data records
tional software. Handling of a DID (Figure 3) illustrates this
>>Provide for unlearning of errors
development. Up to Version 3, signal structures had to be
>>Provide an interface for error readout for the DCM
resolved in the functional software. In Version 4, this task can also be handled by the DCM.
A standardized interface and various debounce algorithms
The DCM is configured based on a ECU Configuration De-
for diagnostic monitors (error path) enable uniform and
scription. This includes the service identifiers, subfunctions,
cross-project development of the functional software. One
data identifiers (with associated signal structure) and rou-
or more error paths can be mapped to a diagnostic trouble
tine identifiers (with parameter lists). In addition, execu-
code (DTC). The DEM is also configured from the ECU Con-
tion of diagnostic requests can be made dependent on the
figuration Description. It contains information related to
current ECU state (session and security level).
error paths, DTC numbers and the structure of extended
The DEM (Diagnostic Event Manager) implements an error
error data (snapshot and extended data records).
memory. Up to (and including) AUTOSAR Version 3.x, the
The FIM (Function Inhibition Manger) makes it possible to
DEM is only specified as a facade, because details of error
inhibit the execution of certain functions in case of active
memory behavior are OEM-specific. Since Version 4, the
errors, start substitute functions and suppress secondary
goal has been to standardize an OEM-independent error
errors. The FIM is also configured from the ECU Configura-
memory, so that its behavior can be defined in AUTOSAR.
tion Description.
The DEM has the following primary tasks: >>Administer the DTC status bit
Basic Software Modules for Diagnostics with AUTOSAR
>>Organize error storage, including NVRAM
Vector’s MICROSAR product line provides an AUTOSAR
2010 Dr. Klaus Beiter leads a development team for the Automotive Diagnostics product line at the company Vector Informatik GmbH in Stuttgart. He is a member of the ASAM/ISO ODX working group.
Oliver Garnatz is employed at Vector Informatik GmbH as a product manager in the Embedded Software Components area. He is a member of the Automotive Diagnostics area of ISO and the AUTOSAR area.
Christoph Rätz is the Director of the Diagnostics product line at the company Vector Informatik GmbH in Stuttgart.
solution for ECU software consisting of the RTE and basic software modules that cover the entire scope of the
SID Request Response AUTOSAR Version
DID
62 FF EE
AUTOSAR standard. Each AUTOSAR BSW module is assigned to a MICROSAR package. The MICROSAR DIAG package is specially available for diagnostics. It contains
22 FF EE
the three BSW modules DCM, DEM and FIM from the
AA BB CC
AUTOSAR architecture. MICROSAR DIAG as the diagnostic software provides vehicle projects with an AUTOSAR- compatible implementation of the UDS protocol ISO 14229-
2.1
3.x
Figure 3: DCM in different AUTOSAR versions
4/10
Data
4.x
1:2006. Note: Part 2 “ODX in the AUTOSAR development process” is also available for download at www.vector.com/downloads/.
4/11
tions can be hierarchically structured and grouped accord-
is limited, because the different application areas place dif-
ing to any desired criteria. Input/output parameters and
ferent requirements on the structure and degree of detail.
diagnostic data (e.g. DTC, DID, etc.) may be allocated to
A generic tester is expected to support as many vehicle
each function. This data is assigned specific values and is
configurations or ECU configurations as possible. A multi-
allocated to diagnostic services via references in the ODX-D
ple or ambiguous description of tester data gives the user
section. Essentially, ODX-FD documents vehicle diagnos-
flexibility here. For example, in ODX it is possible to describe
tics from the perspective of functions. If problems occur in
multiple ECU responses to one diagnostic service. At run-
a vehicle function, the ODX-FD data can be used to deter-
time, the appropriate response is utilized to decode the
mine the relationship between the function and potential
diagnostic data. This is especially helpful if it is not entirely
error sources – i.e. ECUs, sensors and actuators.
clear which specific software is running on the ECU. On the
ODX was released as ISO standard 22901-1 in 2008. ASAM
other hand, unambiguous and exact data description in
published the first version of the standard as ODX 2.0.0 in
specification quality is essential for code generation. It is
2004. Before ISO release, two other ASAM releases were
obvious that the description with multiple responses can-
issued into which corrections, explanations, improvements
not be used to generate the ECU software, because the
and extensions flowed (Figure 2).
ECU must react unambiguously (in a defined way) to a diagnostic request. The example shows that requirements for the (quality of) diagnostic data are different – even
ODX gives the author of diagnostic data wide-ranging
contradictory – for the two use cases.
freedom with regard to the structures used. One and the
Therefore, if the diagnostic software components will be
same behavior can be described differently. This lets users
generated based on ODX, the parts of the standard that
optimally prepare diagnostic data for use in specific test
do not conform to the requirements cited above (specifica-
systems. Nonetheless, support for all conceivable varia-
tion quality) must be excluded.
tions of the standard in processing tools continues to be
The following list identifies some data configurations that
more of an aspiration than reality. It is possible to exchange
violate the specification character. >>Multiple responses to one diagnostic request (see
data, provided that the structures used are supported in
The Standard Mix does it:
both worlds. A commonly used method for documenting
Diagnostics with AUTOSAR and ODX – Part 2: ODX in the AUTOSAR Development Process The Open Diagnostic data eXchange (ODX) format is an XML-based data format for describing the data relevant to vehicle diagnostics. ODX was conceptualized as an open format for exchanging diagnostic data between automotive OEMs and their suppliers. AUTOSAR is the future-oriented reference architecture for ECU software. Clearly specified interfaces, standardized behavior and XML-based data formats are key features of the AUTOSAR standard. This is the second article of the “Diagnostics with AUTOSAR and ODX” series, and it addresses the topic of ODX and how available ODX data can be profitably integrated in AUTOSAR development.
4/12
ODX and ECU Software
the exchangeable contents are authoring guidelines. They specify the type and scope of the ODX subset to be used for the process partners. This approach is established
above). >>Diagnostic services that are not defined for the underlying protocol, e.g. KWP services in a UDS-ECU. >>Multiple diagnostic services with the same service signa-
today. The automotive OEMs who participated in ODX
ture (SID/LID), making it impossible to derive clearly
standardization also took up the process and created an
defined ECU behavior.
authoring guideline for data exchange between automotive OEMs (ODX-RS, Recommended Style). The main motivation for ODX standardization was the desire to standardize the parameterization of data-driven test systems. The data’s usability in other application areas
ODX was standardized in the framework of an ASAM/ISO
the same time, they form the typical content that is re-
working group, initially in ASAM since 2003 and later in ISO.
quired for tester communication with one or more ECUs,
The necessity of ODX development resulted from the lack
including data interpretation.
of acceptance of the previous standard for describing diag-
Jobs
ODX-M ODX-FD
nostic data. The exchange of diagnostic data beyond pro-
diagnostics and so-called Multiple ECU Jobs are described
ECU Configuration
cess boundaries was only possible with tremendous effort.
in the upper four sub-models. Their processing and signifi-
ODX-E
A key goal of ODX standardization is data reuse. It should
cance are lower compared to the first named sub-models.
Flash Data
ODX-F
be possible to use and further process the data with differ-
In this article, only ODX-D and ODX-FD will be discussed in
Vehicle Access
ent tools – including in different business areas.
depth, because these two categories are of special interest
ODX-V
The ODX data model in Version 2.2.0 consists of seven
with regard to AUTOSAR. ODX-D contains the service de-
Communication Parameter
ODX-C
sub-models (Figure 1). The focus of standardization activi-
scription, which defines diagnostic requests and associated
ties was on parameterizing diagnostic testers. Therefore,
responses together with interpretation of the transmitted
Diagnostic Services
ODX-D
the lower three submodels with definition of diagnostic
data.
services, communication parameters and a description of
ODX-FD is an extension to ODX-D, in which diagnostic-rel-
vehicle accesses represent the real core of the standard. At
evant aspects of vehicle functions can be described. Func-
AUTOSAR
The flash container, ECU configuration, function-oriented
Function-oriented Diagnostics
Figure 1: ODX categories
Off-board Tester
Figure 2: ODX history
4/13
The Standard Mix does it:
ODX-E
ODX-V
ODX-FD
ODX-E
ODX-C Authoring Guidelines
ODX-F ODX-M
Tester Model
ODX-D
ODX-FD ODX-F
ODX-V
ODX-C
ECU Specification
ODX-M
ODX-D
Figure 3: Parameterization of test systems via ODX (left). Parameterization of Software Components via ODX using authoring guidelines (right)
source. You will find more information on this subject at:
scratch” (see Figure 4, step 2a). In this case, a large share of
www.autosar-solutions.de and www.odx-solutions.de.
the diagnostic content is prescribed by the OEM. The other
Note: Part 1 “Diagnostics with AUTOSAR” is also available
extreme case involves integrating an existing ECU in a new
for download at www.vector.com/downloads/.
vehicle (see Figure 4, step 2b). Changes to the diagnostics are then only possible with tremendous effort. The diag-
Translation of a German publication in Hanser Automotive,
nostics are therefore influenced much more by the ECU
11/2011
than by functions. In general, neither extreme is exclusively applicable, rather
Literature:
the different approaches are combined. Typically, diagnos-
[1] AUTOSAR specifications: www.autosar.org
tic requirements are specified between automotive OEM
[2] Pascale Morizur, Matthias Wernicke, Justus Maier:
>>Use of special context conventions in error memory: the
cover the use case of tester parameterization. To assure
and the supplier from the functional perspective and ECU
Neue Wege zur Steuergeräte-Software Teil 1, Elektronik
standard does not aim to provide a detailed description
specification quality, numerous consistency checks are
perspective (and the perspective of its periphery), to finally
automotive 11.2009
of error memory in ODX. In principle, it is possible to
necessary, which must exclude data constellations such as
yield the ODX-D data for the ECU.
[3] Pascale Morizur, Matthias Wernicke, Justus Maier:
describe supplemental information for DTCs, but the
those identified here.
In the next step, ODX-FD data can be linked to ODX-D data
Neue Wege zur Steuergeräte-Software Teil 2, Elektronik
standard only specifies the format here (SDG = inter-
In summary, the following picture emerges: ODX was de-
(see Figure 4, step 3). From the ODX-D data, the ECU Con-
automotive 12.2009
leaved list of name-value pairs). The semantics of the
signed to fulfill the requirements necessary for parameter-
figuration Description is generated, which then serves as
[4] ISO 14229: Road vehicles – Unified diagnostic services
data, on the other hand, are not defined; therefore,
izing test systems (see Figure 3, left). However, parame-
the foundation for creating the software components (see
(UDS)
terization of software components assumes that the pos-
Figure 4, steps 4, 5). Furthermore, the ODX-FD and ODX-D
[5] ISO 26262: Road vehicles – Functional safety
sible degrees of freedom are limited to the degree required
data form the foundation for creating the tester run-time
[6] ISO 22901: Road vehicles – Open diagnostic data ex-
describing the dependency of a diagnostic service on
by a specification (see Figure 3, right). This can be achieved
format (see Figure 4, step 7). The use of ODX as a founda-
change (ODX)
session/security levels. The related executability tests
by means of authoring guidelines.
tion for both aspects of the process (software components
[7] Klaus Beiter, Oliver Garnatz, Christoph Rätz: Gesetz
generic processing in automated tools is not possible. >>The widely used ODX Version 2.0.1 lacks a mechanism for
and tester parameterization) ensures that different devel-
liche On-Board-Diagnose und ODX, Diagnose in mecha-
rather they must be implemented in the individual appli-
AUTOSAR with ODX
opment versions of the tester and ECU will match one an-
tronischen Fahrzeugsystemen III S. 44 ff., Expert-Verlag
cation. In the ODX 2.2.0 version, this problem no longer
ODX and AUTOSAR are established standards for develop-
other precisely.
2010
exists. Status information can be formally described
ing ECU software or describing the diagnostic data of a
The question arises whether the reverse process is also pos-
here.
vehicle or individual ECUs. It therefore makes sense to de-
sible, i.e. generating ODX-D from the ECU Configuration
and resulting rejecting responses cannot be generated,
termine how available ODX data might be integrated in the
Description. The answer depends in part on the AUTOSAR
The list shows that conformance to the ODX standard is
development of the diagnostic content of the ECU soft-
version being used: The AUTOSAR format of versions up to
necessary but insufficient to parameterize software com-
ware (DCM/DEM).
and including 3.x is not powerful enough to describe the key
ponents. Checker rules defined in the standard primarily
AUTOSAR development is very function-oriented (see Part
information needed for tester parameterization, e.g. it
1 of this series of articles in the last issue, 10/2011). In early
lacks conversion information for data objects. AUTOSAR 4
phases of development, it is therefore functional descrip-
is more powerful and may contain this conversion informa-
tions and definitions that are primarily created. ODX-FD
tion. Nonetheless, this information in particular is usually
bridges the gap between an ECU’s functions and diagnos-
irrelevant to the use case of ECU parameterization, so it is
tic content, but it is primarily relevant to testers. ODX-FD
questionable whether this information is actually described
data can therefore be derived from AUTOSAR functions,
here in practice.
even if the concrete diagnostic description does not exist
In addition, the function-driven approach prevents cross-
yet in the form of ODX-D data (see Figure 4, step 1). The
vehicle harmonization of the diagnostic contents as de-
ODX-FD description that results reflects the structure and
scribed in this article. Therefore, it remains to be seen which
grouping of AUTOSAR functions in ODX. Linking in the
direction future diagnostic data flows will take. Experience
ODX-D container (i.e. mapping between functions and the
suggests that pure forms of the discussed approaches will
specific diagnostic data) is still not possible at this time
not prevail, but instead they will be adapted to the specific
point.
development situation and combined.
AUTOSAR Functions 2a
OEM/Supplier Coordination
1 3
2b EC U
ODX-FD
ODX-D
EC U
4
7
ECU-C
Generator
Runtime Format
5
*.c *.h 8
6 EC U
Communication
Figure 4: Combination of ODX and AUTOSAR
4/14
extreme case is the new development of an ECU “from
Dr. Klaus Beiter leads a development team for the Automotive Diagnostics product line at the company Vector Informatik GmbH in Stuttgart. He is a member of the ASAM/ISO ODX working group.
Oliver Garnatz is employed at Vector Informatik GmbH as a product manager in the Embedded Software Components area. He is a member of the Automotive Diagnostics area of ISO and the AUTOSAR area.
Christoph Rätz is the Director of the Diagnostics product line at the company Vector Informatik GmbH in Stuttgart.
It was shown above that the information needed to configure software components can primarily be found in ODX-D.
Integration
In AUTOSAR, the ECU configuration is described in the ECU
Integration of the different subprocesses with their various
Configuration Description, from which the ECU software is
interfaces (interfaces, data formats, etc.) is one of the
also generated. It therefore makes sense to transfer the
greatest challenges in introducing new technologies such
ODX-D data (if it exists) to the ECU Configuration Descrip-
as AUTOSAR and ODX. Prior experience suggests that the
tion and use it in the AUTOSAR process. Whether and to
most efficient approach is to rely on practice-proven solu-
what extent ODX-D data exists depends on the coopera-
tions in introducing these technologies. Vector offers com-
tion model between the automotive OEM and suppliers. An
prehensive AUTOSAR and ODX tool chains from a single
4/15
The new specification also provides for new and extended
There are plans to expand the scope of validity of WWH-
functions. For example, the error codes are classified into
OBD to passenger cars, vans, self-propelled work machines,
Severity Classes A, B1, B2 and C, indicating the severity of a
etc. Also being discussed is the elimination of limits to ex-
failure with regard to its effect on exhaust emissions qual-
haust-related systems. For example, it could also be used
ity. Errors of the second highest class B1 also switch to the
to monitor safety-related systems such as brake, steering
highest class A if they are not corrected within a defined
and restraint systems and lighting and examine them in the
time frame that is monitored by the system, e.g. 200 oper-
framework of periodic tests.
ating hours. To ensure that emissions-related functional
WWH-OBD – made simple!
faults and their effects on exhaust emissions immediately
Intelligent WWH-OBD-capable Tools
recognizable to the driver and to authorities and test orga-
Vehicle OEMs must verify the correctness and complete-
nizations, the “Malfunction Indicator Lamp (MIL)” is acti-
ness of OBD functionality in suitable form for registration
vated by errors of the different severity classes in different
authorities. Checking is performed in the framework of
ways.
homologation and assumes that suitable tools are avail-
To also take future requirements and technical progress in
able for verification.
vehicle networking into account, the Internet Protocol (IP)
Both the vehicle OEM and system supplier need suitable di-
is included as a transport medium in standardization in ad-
agnostic tools to test OBD functions in advance of homolo-
dition to CAN. So, in the future UDSonIP will also be per-
gation, i.e. during development or system integration.
mitted in implementations of WWH-OBD.
The good news here is that the information exchanged be-
In some leading industrial nations, the implementation of
tween the vehicle and external tester in the framework of a
WWH-OBD will soon be required as a vehicle registration con-
WWH-OBD is largely identical to the information that is
dition for newly developed models of heavy-duty vehicles.
already exchanged in diagnostics per OBD-II or EOBD.
Effective at the beginning of 2014, for example, all newly
Here, the new standard only specifies minor extensions of
registered heavy-duty vehicles in the EU must conform to
functionality. What will change is primarily only the way in
the Euro-VI standards and must therefore be diagnosable
which these contents are transported.
via WWH-OBD. Newly developed vehicle models must al-
The graphic in Figure 1 illustrates the difference in OBD
ready fulfill the standards by 01-01-2013.
communication based on the previous standard and the
Implementation of the new Requirements for OEMs and Suppliers All new vehicle registrations for heavy-duty vehicles must conform to the requirements of the Euro-VI emissions standard starting in 2014. Vehicle manufacturers are obligated to implement a WWH-OBD capable diagnostic system. Even earlier, guidelines for newly developed vehicles take effect; here the deadline is already on 01-01-2013. Consequently, help in testing the implementation with WWH-OBD capable diagnostic tools is very welcome.
On-Board Diagnostics (OBD) in vehicles involves continual
identical in content – they were developed in parallel to
self-monitoring of the system. Indicator lights immediately
OEM-specific diagnostics and use very different methods,
show the results of this self-monitoring. These results are also
services and parameters.
saved and read-out by an external tester at discrete time
4/16
points, e.g. during maintenance or in the context of a repair.
Global Harmonization of Vehicle Diagnostics
After some carmakers already began to implement such
In OEM-specific diagnostics, there has been a clear trend
concepts as proprietary form back in the 1980s – at that
over the past decades towards increasing standardization
time nearly exclusively in the electronic engine manage-
with regard to transport and diagnostic protocols. Mean-
ment systems – the California environmental authorities
while, a uniform diagnostic interface to external testers
(CARB) in the USA formulated registration requirements
(16-pin OBD socket) and the CAN bus as the transmission
for new vehicle models. These requirements prescribed, in
medium have largely prevailed.
addition to conformance to specific emission limits, a de-
This convergence towards UDSonCAN (Unified Diagnostic
fined set of self-monitoring functions for emissions-related
Services) makes it attractive to merge the diagnostic pro-
systems in a vehicle.
tocols of the legally required and the OEM-specific diag-
Building upon the original OBD version of 1988, legally bind-
nostic contents, which World Wide Harmonized On-Board-
ing OBD content was defined in subsequent years in the
Diagnostics (WWH-OBD) should be able to perform.
rest of the states in the USA as well as in Europe and Ja-
Standardization is occurring at the urging of the United
pan. Although these regionally applicable OBD versions all
Nations in the form of a Global Technical Regulation (GTR)
build upon the same foundation – and in some cases are
and will be specified in the ISO 27145 standard.
Figure 1: Advantage for the user in diagnostic access: Intelligent tools automatically detect which standard is being used, and they automatically adapt to it and deliver the results.
4/17
new WWH-OBD standard. What is displayed is the read-
offers the easy-to-use diagnostic test tool Indigo, which al-
out of currently existing but not yet confirmed Diagnostic
ready supports the WWH-OBD standard today. To ensure
Trouble Codes (DTC), i.e. the “pending DTC”. In both cases,
that the change to WWH-OBD is made very simply!
the vehicle transmits the same error P0198 “Engine Oil Temperature Sensor High” to the scan tool. In the case of WWH-OBD, however, additional information, such as the severity of the error in terms of emissions behavior, as well as its complete status information is also transmitted and
Helmut Frank has worked on many different projects in the automotive industry, including a position as product manager and key account manager in the area of service diagnostic equipment. Since October 2005, he has been employed at Vector Informatik as Business Development Manager for the Diagnostics product line.
CANdelaStudio – Efficient Specification of Diagnostic Requirements at KTM Case Study KTM
displayed. When the byte contents of requests and responses are examined, it becomes clear that their structure appears different in WWH-OBD than it does in OBD-II: First, it is apspecified as three bytes compared to two bytes for OBD-II, where the first two bytes from SAE J2012 or ISO 15031-5 continue to be used. The older OBD version reads out the DTCs separate from their status in different OBD modes, i.e. with: >>Service $03 — Request Emission-Related Diagnostic Trouble Codes for confirmed DTC, >>Service $07 — Request Emission-Related Diagnostic Trouble Codes Detected During Current or Last Completed Driving Cycle for pending DTC and >>Service $0A — Request Emission-Related Diagnostic Trouble Codes with Permanent Status for permanent DTC), WWH-OBD, on the other hand, uses the protocol service ReadDTCInformation [0x19] with the sub-function reportWWHOBDDTCByStatusMask [0x42] and a bit field in Byte 4 of the request to specify the status of the error codes which are to be reported. An intelligent test system, such as Indigo from Vector, is able to independently recognize the standard upon which the test is based, provide the relevant functions for the pertinent OBD standard and in the process make the protocol-specific differences transparent to the user. This lets users focus on the contents in their work. If necessary, the user can also delve into the depths of the protocol and analyze the raw data. This is useful, for example, in determining the causes of errors, if the ECU does not provide the expected response to an OBD Request. Summary Modern high-performance diagnostic tools must offer full support of the new WWH-OBD standard – and they must do so immediately. They can very well help to achieve compliance to regulations within the rapidly approaching deadlines of the beginning of 2013 and the beginning of 2014. They fit seamlessly into existing tool chains and make the
The Customer
The Advantages
The KTM-Sportmotorcycle AG with registered office in
A standardized diagnostic data format and the Front
Mattighofen, Austria produces and develops race-ready
loading Appraoch provide the KTM developers time for
offroad and street motorcycles. KTM is the largest motor-
additional testing and thus a higher product quality.
cycle manufacturer in Europe and a leader in the offroad
With CANdelaStudio, KTM significantly reduces its effort
competition sector. In MY 2014, the 1190 Adventure has
for the diagnostic requirements specification phase. ECUs
been turned into what is currently the worldʼs safest motor-
with diagnostic capability are available at an early stage.
cycle.
Diagnostic specifications can be used, on the one hand, for automated generation of ECU software or for parameteriza-
The Challenge
tion of diagnostic tester. On the other hand, they are avail-
Consistent creation, management, and distribution of diag
able for reuse in new or further ECU development projects.
nostic data throughout the diagnostic development process.
The result: The entire diagnostic development for the ECUs
In the development of the new 1190 Adventure, and its up
of the KTM 1190 Adventure motorcycle was completed
to 9 ECUs, an optimization of the diagnostic development
much faster than for earlier motorcycle models.
process should be performed. In previous development
More benefits: > Existing diagnostic tester at KTM, such as CANoe, can
projects, diagnostics was specified in text form at KTM. Automated further processing of the specification was therefore not possible. Rather, the ECU specification
be parameterized at an early stage in the process > ODX data for parameterization of KTM production and
required time-consuming interpretation and conversion
service testers are generated directly from CANdelaStudio
into input data for the utilized diagnostic testers both
at the press of a button. KTM developers do not have to
internally at KTM as well as at the ECU suppliers. Thus diagnostic testers in development, production, and service became available only at a late stage.
be specially trained in ODX. > Easy creation of diagnostics requirements as PDF data for “smaller” KTM suppliers is still possible. > Coordination of diagnostic specification between the
The Solution
process participants (KTM and suppliers) is much easier.
The CANdela approach – a standardized diagnostic data format and the corresponding tool chain. CANdelaStudio is used as a central component of the
[Time]
CANdela approach in the development of diagnostics for
Effort for ECU diagnostics development
the new 1190 Adventure motorcycle. The KTM developers use this to specify diagnostic data in machine-processable
with CANdela approach
CDD format (XML). Thus these data are available at an early stage as input data for many tools throughout the diagnostic development process. Text-based specifications can be generated also out of the CANdela description and forwarded as needed to KTM suppliers still at the same time.
Requirements
parent that the length of error codes in the WWH-OBD is
migration to WWH-OBD especially simple for vehicle OEMs V2.0 | 2014-07
and suppliers. Experience has shown that it is best to rely on the most efficient and practice-proven solutions. Vector
4/18
Vector Informatik GmbH | www.vector.com/contact
4/19
ments that are unnecessarily specific can often actually
Standardized exchange formats are specially designed for a
obstruct the path to the quickest and most cost effective
specific discipline. ODX, for example, specifies data that is
solution. If aspects of a solution path are intermixed with
relevant to the diagnostic tester. Exchange formats usually
requirements early on, this unnecessarily reduces the solu-
use a formal data model that assures a consistent specifi-
tion space. Often, this also eliminates the opportunity for
cation that is complete in its details. On the other hand,
re-use. Especially when requirements change over the course
these formats are too restrictive for formulating fuzzy re-
of development, it is important to separate the substantial
quirements. Classic requirement management tools are
requirements from relicts of earlier solution approaches.
well-suited to describing text-based diagnostic require-
During development, the totality of implementation prog-
ments. The standardized data exchange format ODX,
ress for all requirements offers a good overview of the im-
meanwhile, would be unsuitable for describing or exchang-
plementation progress of the total system or of a subsys-
ing these text-based requirements, because it is too formal
tem (maturity level tracking).
and precise.
If you want to systematically exploit the advantages of a
From Diagnostic Requirements to Communication Standardization is the Trend in the Development of Automotive Electronics A key aim of open architectures, configurable components and harmonized exchange formats is to let developers focus more on the development and reuse of innovative and product differentiating functions. In recent years, a number of independent standards have been created, all of which have affected processes and tools for diagnostic development – in particular ODX and AUTOSAR. At the same time, the systematic capture, management and tracking of requirements
requirements-driven process, then the process described
ECU Software
above must be applied to all subsystems, including those of
Today, AUTOSAR (AUTomotive Open System ARchitecture)
different development disciplines that are actually inde-
is the reference architecture for ECU software in the auto-
pendent. Naturally, this also applies to diagnostics.
motive industry. AUTOSAR standardizes the description of
Today, spreadsheet-oriented tools and databases are usu-
individual component or vehicle functions and the descrip-
ally used to manage requirements. Here, requirements are
tion of the overall system.
either not described formally, or they are only described
The diagnostic software in AUTOSAR consists of the three
formally in part. These tools must be flexible enough to
basic software modules DCM, DEM and FIM.
capture and track all requirements – even those that are
The DCM (Diagnostic Communication Manager) imple-
very fuzzy.
ments diagnostic communications according to UDS and
Regarding the specification, various other tools have be-
OBDII. The DEM (Diagnostic Event Manager) implements a
come established in the various disciplines, e.g. modeling
fault memory and manages fault status and supplemental
and authoring tools, which usually generate a formal spec-
information on fault symptoms. In the case of active faults,
ification. In contrast to user requirements, precise defini-
the FIM (Function Inhibition Manager) prevents execution
tion of the content is the primary goal and not flexibility,
of certain functions and suppresses secondary errors.
and this fundamental difference results in different, spe-
DCM, DEM and FIM are configured by the ECU Configura-
cialized tools. Consequently, classic requirement manage-
tion Description (ECUC). Their contents are best under-
ment tools can only be used meaningfully up to a certain
stood by illustrating how requirements relate to the config-
level of detail. This also applies to diagnostics.
uration of software components.
took hold, which also had a significant impact on processes, methods and tools.Is it possible to do without one or more standards? Is there a super-standard? Or can the standards and methods be combined with one another effectively and efficiently?
4/20
Requirements Engineering
the specification. Formal languages are often used for the
The development of a system starts with the requirements
description, which are appended to text-based require-
from the user’s perspective. The capture of requirements
ments in files. Reference requirements contain a reference
marks the beginning of an iterative process (Figure 1), in
to a specification, e.g. “as in the previous system”. Techni-
which requirements of a system are progressively made
cally, these reference requirements actually reference spec-
more specific and precise. If the solution space for fulfilling
ifications in other databases or data management sys-
requirements is still large, the later specification describes
tems in many cases.
individual subsystems precisely and without ambiguities.
Ideally, requirements are defined as precisely as possible
In practice, requirements differ in terms of how specific and
from the start, but only as specifically as necessary. Un-
precise they are. Text-based requirements describe a sys-
clear or ambiguous requirements lead to considerably in-
tem property to be fulfilled in text form, usually incom-
creased effort over the course of the development process,
pletely and purposely fuzzy, phrased or just in note form.
because clarification means there is a need for additional
Specification requirements, on the other hand, are precise
coordination, and it often results in a specification change.
and not only describe the requirement itself, rather they
In the least favorable case, the system implementation
also include the solution and leave very little freedom for
may even need to be modified. On the other hand, require-
Figure 1: Iterative development process
4/21
From Diagnostic Requirements to Communication
Fuzziness and flexibility, which are advantageous in captur-
vice area, a single diagnostic tester needs to cover a large
specifying ECU diagnostics, because CANdelaStudio sup-
on the ECU descriptions in ODX or cdd format, which are then
ing requirements, must be avoided in configuring the ECU
number of different vehicles, models and variants over
ports the capture and import/export of requirements. Di-
automatically executed in CANoe. Test results are shown in
software. The software must be described precisely and
many model years. The resulting volume of data requires
agnostic objects (diagnostic services, data objects, DTCs)
detail, and the user can comment on any test cases, or
unambiguously for all operating conditions that occur.
efficient mechanisms to avoid redundancy and to achieve
are generated at the press of a button from the require-
group, sort and filter them according to various criteria.
Significant contents of the diagnostic data that are rele-
compact storage of the necessary data.
ments, which are already formally described. These objects
vant to the software configuration include the diagnostic
The specification character required for configuration is
are each linked to an original requirement. In this way, the
Using ECU Diagnostics
services that can be called by an external diagnostic tester
not really necessary for parameterizing testers; on the con-
user can have the imported requirements automatically
CANoe, CANape or Indigo is used as the diagnostic tester, de-
with request/response and their parameters (service iden-
trary, it may even be advantageous for a parameterization
adapted and synchronized to match updated require-
pending on the application area. Having the CANdelaStudio
tifier, sub functions and data parameters). The length and
to contain multiple equivalent alternatives, because the
ments, and if necessary the specification can be modified.
specification as a common source for tester parameteriza-
data type are relevant for all data parameters; constant
appropriate data can then be automatically selected at
Closely interlinking requirements and specification is very
tion and ECU configuration ensures that the tester and
parameters also require a constant value. In UDS, access to
runtime. When a diagnostic tester is connected to a vehicle,
advantageous in the typically iterative process, because it
ECU software match one another.
certain data packets may be restricted to certain sessions
it is often unclear which ECU variants and software levels
avoids duplicated efforts in creating and re-comparing the
or security levels. This information is also contained in the
are installed in the vehicle under test.
specification data.
Summary
configuration data, so that the software can assure con-
In terms of content, the diagnostic tester data differs from
The finished diagnostic specification serves as the input to
The AUTOSAR and ODX standards that have appeared in
formance to the prescribed rules.
the configuration data in that conversion information is an
subsequent steps in the process chain. CANdelaStudio
the diagnostics area in recent years complement one an-
The second important aspect of the software configura-
essential component. The compactly coded bus messages
saves the native diagnostic specification in cdd format, and
other well and continue to be effective in meeting objec-
tion data is that it links the diagnostic software to the
and their parts are displayed as physical values with units
an ODX file can also be exported at the press of a button.
tives. Although they cover related contents, they have very different areas of focus and overlap just slightly (Figure 3).
application. The parameters passed by diagnostic services
at the tester.
can be linked to variables or functions of the application
Examples of established data formats for parameterizing
Generating and Integrating ECU Software
The operation area of the one standard cannot be covered
software. Software generators can then generate the rele-
diagnostic testers are the cdd format from Vector and the
DaVinci Configurator Pro is a tool for configuring and gen-
by the other. The AUTOSAR method is also compatible with
vant calls.
ISO-standardized ODX format.
erating the AUTOSAR basic software and an ECU’s RTE.
ODX.
Since AUTOSAR diagnostics is limited to the UDS and
The user imports a diagnostic specification (ODX or cdd)
In practice, however, there is still the challenge of assuring
OBDII protocols, the layout of diagnostic services of these
Example of a Tool Chain
and generates an initial ECUC configuration from it. After-
consistency of the data described in the different stan-
protocols is implicitly assumed and is not explicitly de-
During diagnostic development, the following tasks are
wards, the user progressively supplements the configura-
dards over a distributed and usually iterative development
scribed in the ECUC data.
performed, which are supported by the tool chain shown in
tion for the ECU and makes it more specific and detailed. If
process. This challenge can be overcome by a well-defined
The AUTOSAR ECUC data is stored in a standardized XML
Figure 2.
there is a new version of the diagnostic specification, it is
process, targeted data transfer and support by tools avail-
easy to re-import it, and the contents are automatically
able on the market today.
format, which enables its processing in code generators. Defining, Gathering and Coordinating Requirements
merged with those of the previously created configuration.
Supplying Data to Diagnostic Testers
IBM DOORS is widely used among automotive OEMs as a
The diagnostic software for the ECU is generated based on
Diagnostic data used to parameterize generic testers must
tool for capturing and managing requirements.
the resulting configuration.
from the perspective of diagnostic communication. A sig-
Creating and Coordinating the Specification
Testing ECU Diagnostic Software
nificant difference compared to the configuration data
Here, CANdelaStudio can be seamlessly integrated into the
CANoe.DiVa is used to test the diagnostic implementation
described above is the vehicle scope. Especially in the ser-
requirements-driven process chain as an authoring tool for
in the ECU at both the supplier and the OEM. CANoe.DiVa
contain all information relevant to the vehicle or its ECUs
generates an extensive set of ECU-specific test cases based
Figure 2: Tool chain of diagnostic development
4/22
Dr. Klaus Beiter leads a development team for the Automotive Diagnostics product line at the company Vector Informatik GmbH in Stuttgart. He is a member of the ASAM/ISO ODX working group.
Christoph Rätz is the Director of the Diagnostics product line at the company Vector Informatik GmbH in Stuttgart.
Figure 3: Contentual similarities of the several description models
4/23
special knowledge, and it can be used later to easily verify
edge in this process. The service shop employee can execute
the success of a service repair.
supportive actions – such as activating the brake pedal –
As consequence the diagnostic testers – differ considerably
while the expert reads out measurement values and pre-
based on these very different requirements – with regard to
cisely observes the behavior of relevant vehicle compo-
their user control concepts, level of detail and access capa-
nents. If vehicle conditions permit, it is even possible for the
bilities. Accordingly, a service shop tester only makes a part
expert to have access to actuators from a distance. The
of the diagnostics implemented in the ECU available, while
expert can use further actions to confirm initial suspicions
other parts are reserved for development or production.
of a reason that could explain the observed behavior, or
However, if an unexpected problem now occurs in the field,
else exclude it as a cause, and can thereby effectively deter-
the experts may sometimes require access to precisely
mine the cause of a problem.
these development-specific information or functions.
For our test driver in Sweden mentioned above, this means that the expert neither has to quickly travel to Sweden nor
Diagnostics from a Distance Interactive Diagnostics for Vehicles Worldwide
Data Protection
is it necessary to send the development diagnostic data to
However, the general distribution of all diagnostic data
the test driver for attempting to resolve the problem on his
with the customer service tester is not a solution either, be-
own – under the guidance of the expert. It is also unneces-
cause this would also make undesirable and very wide-rang-
sary to reproduce the problem after returning from Swe-
ing system interventions possible, interventions that should
den, if it is possible to study the matter right away locally.
experts. actually be reserved for just a small group of
This is especially important if the specific environmental
Therefore, the data and functions are handled confidential-
conditions have an effect on the observed behavior.
ly and are only accessible to a small group of users. This
A primary advantage of remote diagnostics, however, is that
also makes it more difficult for unauthorized third parties
the expert can react immediately to measurement results,
to gain access to information on how functions of individu-
conduct additional measurements, modify parameters and
al systems are implemented or to manipulate them. There-
address actuators. This interactive access capability also il-
fore, precisely those parts of diagnostics are selected for
lustrates the significant difference between remote diagnos-
Vehicle diagnostics is an important tool for quickly and efficiently localizing and correcting faulty behavior of individual
the customer service tester that are needed for use cases
tics and the approach of using a logger or onboard tester.
vehicle components. In certain rare cases, however, it may not be possible to find the cause of the error locally without
in the service shop – user operation is made as simple as
the support of an expert. This expert can now access the vehicle directly and interactively – even without having to be on
possible, and unintentional operating errors are prevented.
site locally – using remote diagnostics, and can then examine the vehicle and systematically determine the cause of a problem.
Remote Diagnostics with High Levels of Performance and Data Protection
Interactive Remote Diagnostics
The benefits of interactive remote diagnostics succeed or
Using interactive remote diagnostics, the difficulty of phys-
fail with the ability to process diagnostic inquiries at a high
ical separation of the expert from the vehicle is circumvent-
rate of speed and with low latency. The new Version 4.0 of
Sweden, -20 °C, snowfall. A test driver conducts a test drive
pliers can also benefit from remote diagnostics to diagnose
ed. Experts can access the vehicle as though they were
the Indigo diagnostic tester from Vector (Figure 1) sup-
on a frozen lake covered with snow. During a braking ma-
their systems at later production startup.
present locally, and they can contribute their expert knowl-
ports the interactive remote diagnostics described above.
neuver in a curve, he notices some unusual vehicle behavior.
And even in the service shop situations sometimes occur, in
He suspects that the cause lies in the brake system. After
which it is essential to get the advice of an expert. In some
additional trials, the experienced test driver quickly recog-
cases, this is the only way to accomplish a quick and
nizes that the behavior only occurs under very special con-
cost-efficient repair when an unpredictable and complex
ditions.
problem exists.
Although the test driver is very familiar with the vehicle, a precise analysis by a system developer is necessary. Only
Diagnostics with Different Focal Points
the system developer has the necessary background knowl-
Effective vehicle diagnostics is a key factor for achieving a
edge needed to quickly and comprehensively find the cause
high level of customer satisfaction with regard to the dura-
of this behavior. However, it is very rare for this engineer to
tion, cost and success of repairs.
be available locally to read out key vehicle data and drive
It is an indispensable tool, which accompanies the vehicle
actuators for test purposes using vehicle diagnostics.
over its entire life cycle – from development to production
With remote diagnostics, the expert can now access the
and finally customer service. Very different requirements
vehicle despite the long distance from it, without having to
are set in the various life phases, which must be considered
quickly travel to Sweden.
in the development of diagnostics. During vehicle development, a deeper look into the ECU and more extensive inter-
4/24
Use Cases
ventions are needed. In production, diagnostics is used for
Easy remote access to a vehicle or its components by ex-
the “OK / Not OK” test. In customer service, guided trou-
perts is not only helpful during test drives. OEMs and sup-
bleshooting helps to localize errors without requiring very
Figure 1: Diagnostic tester Indigo: Fault Memory and Measurement
4/25
Diagnostics from a Distance
To use remote diagnostics, it is sufficient to download the
nificantly from a remote desktop approach with regard to
access point on the vehicle side and invite the experts to a
data protection and performance.
diagnostic session with an ID and password. It is especially
The diagnostic tool makes it possible to study unexpected
noteworthy that no changes need to be made to the vehicle
behavior on test drives over great distances, and it also sig-
for the test system to be immediately ready for use.
nificantly shortens repair times when unexpected problems
With the implemented solution, the diagnostic data, test
occur in the service shop. In service shops, in particular,
sequences and security algorithms remain within a pro-
efficient third level support with remote diagnostics can
tected environment – all control, interpretation and evalu-
reduce repair time and costs and deliver a high level of
ation actions are performed on the expert’s computer. A
customer satisfaction.
high level of data security is achieved in conjunction with end-to-end encoding. In order to efficiently use full diagnostic capabilities efficiently, a number of technical measures are implemented to assure high bandwidth and low latency. This makes it Figure 2: Classic Diagnostic Tester
Rolf Weber is team manager and product manager at the Diagnostics product line at the company Vector Informatik GmbH in Stuttgart. He is responsible for the test systems area within diagnostics, representing the diagnostic tester Indigo and the flash tool vFlash.
possible to access vehicles with very short response times worldwide – even when transmitting large amounts of data.
By comparison, a classic diagnostic tester is connected
Summary
directly to the vehicle via a network interface (Figure 2). In
By using interactive remote diagnostics, a system or diag-
this case, all necessary diagnostic data and the required
nostics expert can connect to a vehicle anywhere in the
diagnostic and module knowledge must be available locally.
world and examine errors locally and at the same time as
When using remote diagnostics in Indigo, the classic diag-
they occur.
nostic tester is replaced by an access point. Together with
In this process, the expert does not need to rely on a locally
the communication server on the Internet, it serves as a
available test system optimized for customer service, but
routing hub and routes diagnostic requests and responses
can use an expert tool instead. Yet, the data required for
between the vehicle and the actual diagnostic tester
diagnostics does not need to be distributed or transmitted
(Figure 3). The actual diagnostic tester is located remotely
– the data remains in the protected expert environment.
at the location of the expert. Neither the diagnostic data
The interactive remote diagnostics offered by the Indigo
nor the expert needs to be sent on a trip – and yet it is pos-
diagnostic tester from Vector goes far beyond the static
sible to access the vehicle directly.
diagnostics of an onboard test system and also differs sig-
Christoph Rätz is the Director of the product line Diagnostics at the company Vector Informatik GmbH in Stuttgart.
Figure 3: Concept of interactive remote diagnostics with Indigo
4/26
4/27
DE VELO PMENT DIAGnO STIC S
© Claas, Vector Informatik
TASKS
AUTHORS
Automated Data-driven Validation of the Diagnostic Implementation
Using automatically generated tests for the validation of diagnostic protocol implementation has been practiced for many years. This process is based on diagnostic description files
Dipl.-Ing. (FH) Nils Niedermark works as Development Engineer in the Development Electronic Integration Department at the Claas Self-propelled Harvesters GmbH in Harsewinkel (Germany).
Friedemann Löw, B. Sc. is Developer for the Automotive Diagnostics Product Line at the Vector Informatik GmbH in Stuttgart (Germany).
from the automotive OEM. The ECU’s diagnostic interface can be efficiently tested in a verifiable way, and this leads to an improvement in product quality. In addition, automated validation of diagnostic parameters and error codes is also possible – depending on how complete the diagnostic description is – as shown in a joint project by Claas and Vector. 22 4/28
Dipl.-Inf. Simon Müller works as Product Manager for the Automotive Diagnostics Product Line at the Vector Informatik GmbH in Stuttgart (Germany).
Claas, an agricultural machine manufacturer, describes the interrelationships between diagnostic parameters and ECU inputs and outputs in its diagnostic data. The description of error setting criteria is formally documented for new implementations. In the past, this information was used to perform manual tests, or test engineers implemented special test cases. However, it was still not possible to attain broad test coverage. In cooperation with Vector, this information relating diagnostic parameters and ECU I/Os is being automatically linked to the existing network (communication matrix) and hardware description. Fully automated diagnostic implementation tests are generated and executed in a test environment based on existing specification data such as CDD (CANdela Diagnostic Data) or ODX (Open Diagnostic Data Exchange). Correct diagnostic hardware and software integration is tested by automated stimulation of the ECU environment. This is done by modifying signals in the bus simulation or driving specific hardware I/O. So it is possible to test the correct setting of diagnostic parameters, or generate error states and test for their proper memory storage. AUTOMATED TEST GENERATION
To attain automated test generation and test execution of implementation tests, the diagnostic parameters and ECU I/O must be correlated to each other. Besides the diagnostic data (ODX, CDD), specification data that indirectly references diagnostics is also used. This might include network descriptions (dbc, arxml) or environment configurations such as the interface description of an HiL configuration. This system information can be used to stimulate and measure an ECU’s inputs and outputs in a test environment. Today, the interdependencies between the diagnostic and ECU environments are typically not described formally in the diagnostic data – if they are described at all, they are typically described in natural language. This generally makes it impossible to further process it by automated methods. Heuristics can be of help here and at least enable some use of this information for test 06I2015
Volume 10
automation. If additional detailed OEM-specific knowledge about the type and scope of the ECU I/O description exists, they can be used to derive tests of the diagnostic implementation. In particular, this enables automated diagnostic parameter tests and fault memory tests. FAULT MEMORY TESTS
The structure and formal contents of the fault memory data are taken from the diagnostic data, such as the layout of the environment data from DIDs (Data Identifiers) and conditions for setting DTCs (Diagnostic Trouble Codes). The latter, however, usually exist in a non-formal description. If the diagnostic description can be interrelated to the ECU’s periphery, then it is possible to test whether a DTC is stored correctly in fault memory and under the proper conditions. In addition, it is possible to validate DTC status transitions and proper clearing of DTCs. The specific setting condition must be known for each DTC. This consists of at least the following: – I/O type (input or output, network or sensor/actuator) – I/O name (message name, channel name) – error pattern (e.g. short circuit to ground). The error pattern can often be derived directly from the standardised Failure Type Byte (FTB) of the DTC (SAE J2012). Depending on the error pattern, additional information might be needed: threshold values, setting times and information on error monitoring. DIAGNOSTIC PARAMETER TESTS
Analogous to fault memory tests, diagnostic parameter tests need to know the relationship between diagnostic parameters and the ECU pins. A diagnostic value can be validated by comparing it to a: – measured value at an ECU pin – Bus signal – CCP/XCP signal. In addition to the I/O type and name, conversions are also necessary to enable comparisons – such as conversion of a resistance value at a sensor to a temperature value in the diagnostic parameter. The updating frequency of the diagnostic parameter or ECU output must also be
considered. Furthermore, test values are needed for the I/O stimulation, because they are seldom documented in the diagnostic description, and suitable values generally cannot be derived from specification data. For both fault memory tests and parameter tests there may be preconditions for the availability of a function to be tested. For instance, grinding the blades of a field chopper requires that the main drive is activated. These interdependencies must be known and considered at test execution. GOALS AND IMPLEMENTATION AT CLA AS
At Claas, much of the data required for implementation tests are described formally. Therefore, the goal is to automate test generation and execution based on this information. To accomplish this, Claas uses the CANoe.DiVa tool from Vector. The I/O information in the diagnostic description (CDD) and from other sources is imported into CANoe.DiVa to parameterise a test generator. Afterwards, the generated implementation tests are automatically executed in the CANoe test environment that already exists for the ECU under test, FIGURE 1. Claas manages all data relevant to the implementation tests in a development database. Since the data is also imported into the diagnostic description file, this file is usually sufficient to generate the parameter tests. Additional conversion information is only needed for I/O’s which use different units in the diagnostic parameter than at the ECU pin. They are contributed in the form of a CANoe mapping that maps signal values to CANoe system variables via a conversion rule. This data can be used to automatically parameterise and generate three different parameter tests: – Input tests: The test environment stimulates a sensor pin of the ECU. The associated diagnostic parameter is read out, and it is compared to the value at the pin. – Output tests: A diagnostic service (I/O Control) writes a new value to the ECU, which causes it to drive an actuator. Afterwards, the value at the output is measured and compared to the value of the written diagnostic parameter.
23 4/29
DE VELO PMENT DIAGnO STIC S
FIGURE 1 System architecture: automated diagnostic implementation tests at Claas (© Vector Informatik)
FIGURE 2 Test setup at Claas for measuring and stimulating voltages at ECU pins with the VT System from Vector (© Claas)
– Passive tests: Some signals cannot be controlled by a diagnostic service; rather they can only be read out. They are controlled solely in the ECU application bypassing the diagnostic layer. In this case, a test can be generated
24 4/30
which reads the value at the diagnostic service and compares it to the value at the ECU input or output. In contrast to parameter data, some of the data needed for fault memory tests at Claas do not exist fully in the diagnostic description. They are therefore exported from the development database as an Excel file and are read in for test parameterisation. In the test derived from this data, the I/O of an ECU is stimulated to create an error situation. Afterwards, the test verifies whether the correct DTC was stored in fault memory. DTC status transitions and DTC environmental data stored for the error can also be verified by having the test correct the error situation, implement wait times and set the error state again. The fault memory tests are rounded out by checking the clearing of fault memory on different safety levels. To measure and stimulate voltages and currents at the ECU pins, Claas uses a HiL system from Vector– the VT System, FIGURE 2. In order to automatically drive the VT System using the data of the diagnostic description and the development database, name conventions were defined for the VT System configuration. INCREASING TEST COVERAGE
At Claas, diagnostics-capable ECUs are not only found in combine harvesters
and tractors, but also in such machines as mowers and baling presses. In the largest Claas machines, up to 40 ECUs may be installed depending on equipment options. Implementation tests must be conducted for all of these model series. This verifies that the ECU modules can be controlled by the Claas Diagnostic System (CDS). The largest ECU installed by Claas has more than 75 I/Os, with up to 15 different machine functions implemented, depending on the installed machine options. Associated with these I/Os are over 200 DTCs that must be checked in testing. Automating the generation and execution of more implementation tests reduces the effort required for validation of the ECUs tremendously. OEM-specific extension of the test tool at Claas enables greater test coverage by automated tests of fault memory and diagnostic parameters: from a previous 55 to 95 % currently. Claas has set a goal of subjecting all of its ECUs to automated implementation test with CANoe.DiVa. The effort required for diagnostic tests of hardware I/O is high, despite automated test generation and test execution. Setting up the test environment is especially time-consuming. Depending on the specific ECU, it can be very complex to drive individual I/Os, and individual access must be implemented. By contrast, validating diagnostic parameters with reference to network signals can be implemented with low initial effort: The necessary infrastructure can be automatically generated by generating a remaining bus simulation from the communication matrix, which can then be used by the test.
Similarly, there are also preconditions for some fault memory tests that need to be met before an error monitor becomes active and a DTC can then be recognised and stored in fault memory. The currently implemented tests can still be supplemented by further details such as testing of self-healing functionality, prioritisation of fault memory storage and to test different error situations that lead to the same DTC. The test solution will be continually developed further in these areas. In the automotive industry, there is also a noticeable trend toward merging devel-
opment data for electrical and electronic architectures. Databases and tools thereby obtain information, either directly or indirectly, that can be used to automatically test electrical installation and electronic integration with diagnostic software. Further formalisation of data is associated with greater effort initially. Above all, formal description leads to a rewarding high optimisation potential for automated tests which is well worth the effort. Progress in standardisation (e.g. Autosar) and the integration and interoperability of development tools are leading to a
wide variety of new approaches in the field of automated testability. CANoe. DiVa is following this trend and will make use of these new opportunities for deriving further automated tests of the diagnostic implementation. The possibilities for automated, datadriven tests have hardly been exhausted, and this field will remain exciting. REFERENCE [1] Peti, P.; Timmerberg, A.; Pfeffer, T.; Müller, S.; Rätz, C.: Automatic validation of diagnostic services. In: ATZelektronik worldwide 3 (2008), no. 6, pp. 30-35
SUMMARY AND OUTLOOK
Automated generation and execution of tests – such as those performed at Claas with the CANoe.DiVa tool from Vector – offer great potential for increasing depth of testing while reducing test effort. Currently, for full test coverage with CANoe. DiVa, some functionalities must still be manually configured at Claas, because no formal description is available that could be used for automated parameterisation. For instance, there are I/O’s whose control is very complex in parameter tests. Here, some preconditions in the ECU environment must be satisfied before it is possible to use the I/O as intended. 06I2015
Volume 10
25 4/31
From the Virtual Calibration to the Automatically
expensive special software and its time-consuming config-
Generated Parameter Set
uration, a cloud solution is a straightforward means of
Other trends include calibration in virtual environments,
providing simple sharing of measurement data as well as
automatic generation of knowledge from existing data-
central algorithms for data mining.
sets, and migration of web technologies into industrial work sequences. While calibration has shifted in recent
Future-proof Tool Chain for ECU Calibration
years away from the vehicle to test benches and HIL sys-
All of these trends will have a lasting impact on the tool
tems, in the future more calibration tasks and optimiza-
chains for measurement, calibration, and diagnostics in the
tions will be carried out with simulations and models in the
coming years. As a tool manufacturer supplying high-per-
lab (Figure 1). This spares companies the need for expensive
formance products for ECU calibration to customers both
prototypes and test vehicles. The approach will no longer
now and in the future, Vector is focusing intensively on
be simply to measure signals and collect and manage data.
these trends. The company has identified four strategic
Rather, automatic generation of results will be the focus.
topics in the area of ECU calibration that it is concentrat-
The existing database will serve as the basis for creating
ing its efforts on: assistance systems, added value in power
new parameter sets and variants using corresponding cal-
train, flexible interfaces that allow tool departments of
culation algorithms.
companies or external service providers to easily integrate Vector products in their solutions, and integrated, reliable
Reliable, Value-added Integration of Cloud Technologies
provision of Internet technology in measurement and cali-
Social Media, Internet of Things, and Web 3.0 are showing
bration solutions.
us how data exchange, connectivity, and expandability can be
Trends and Effects on Development Methods and Tools Calibrating ECUs
realized today in a simple, all-encompassing manner using
Current Solutions Ideally Suited for Further Development
apps. It is a matter of providing the potential of these ap-
Calibration tasks in power train are multi-faceted and
proaches as integrated, reliable company solutions in order
range from measurement data acquisition to offline cali-
to tap into it for measurement and calibration applications.
bration. The latter focuses on working with measurement
For example, applications for measurement data analysis
files and parameter values. The application engineer cre-
offer excellent potential for added value through use of
ates and manages variants or uses model-based or virtual
these technologies. While previous solutions required use of
technologies for optimization and dataset generation.
The developments and challenges of the next five to ten years in the area of measurement and calibration of ECUs will be determined by global trends and will involve several changes. Established work methods are frequently reaching their limits, and adoption of new approaches by companies is inevitable. Data-based calibration methods, “intelligent” data management with virtually transparent data exchange, and flexible integration of expert knowledge via apps, among other things, will supplement the work of the application engineer.
In the view of numerous managing directors in the auto
The complexity and configurability of ECUs is also continu-
motive industry, the key trends influencing this sector in
ing to increase in other electronics areas such as the chas-
upcoming years will include handling of new markets,
sis or body and for assistance systems. Even if only 5000
standardization of vehicle platforms and modules, driver
parameters have to be managed for chassis systems, engi-
assistance systems, and further optimization of internal
neers must ensure this for 80 to 100 product variants. In
combustion engines [1]. This will create new demands on
the case of ultrasonic sensors, a typical component of as-
companies and their development departments, requiring
sistance systems, there are only a few calibration values
fundamental changes to many work methods.
but the sensors are installed in 1000 vehicle variants.
For example, while new markets require much closer col
Efficient development, testing, and validation of driver as-
laboration with customers, business partners, and service
sistance systems is possible only through direct integration
providers at the international level, more standardization
with the existing measurement and calibration tool. In ad-
might lead to a greater number of variants. Further devel-
dition to high data rates, the sensor data fusion calls for
opment of combustion engines, in turn, will further increase
expansion of existing signal-oriented concepts in the direc-
the already high level of complexity of the power train.
tion of object-oriented representation and processing of
Today’s modern diesel drives with exhaust gas cleaning
information.
already require calibration of over 60,000 parameters, with 4, 8, 10, or 20 variants.
5/0
Figure 1: ECU calibration is increasingly shifting from the vehicle to test benches and HIL systems. To reduce costs for expensive prototypes and test vehicles, more calibration tasks and optimizations are being carried out with simulations and models in the lab.
5/1
Trends and Effects on Development Methods and Tools
What is meant here is an integrated offering of tools that are all equipped with a uniform user interface and the same look and feel. The tools provide similar methods and allow editing, management, and analysis of calibration data using a variety of tools. Essential features of the Calibrators Workbench will include expandability using apps or vApps (virtual apps). This will enable engineers to reuse existing functionality (reading/writing of measurement files, parameter set files, map editors, etc.) for their own applications, which reduces development expenses. It will thus be possible to buy additional expert knowledge when needed and easily integrate it into the Calibrators Workbench. The apps equipped with server or cloud infrastructures can originate from Vector or external service providers. Figure 2: As part of model-based software development, the functions of applications are tested in an iterative process. A convenient measurement, parameter assignment, and visualization interface for models such as CANape significantly accelerates the development process.
As a central node for knowledge management, Calibrators Workbench will ultimately provide a simple cloud- based sharing of work results. Translation of a German publication in Hanser Automotive 11-12/2015 List of references: [1] KPMG’s Global Automotive Executive Survey 2014 – Strategies for a fast-evolving market
High-performance solutions for various offline task areas
CDM Studio is a stand-alone calibration data handling tool.
are already available today and form an ideal starting basis
vCDM is an enterprise solution for calibration data man-
for further development. The palette includes a range of
agement. CANape, which in combination with Simulink, is a
Image rights:
tools. vSignalyzer is a measurement data analysis tool.
powerful platform for model-based calibration (Figure 2).
Lead figure: © Fotolia.com/vege, edited by Vector
The bandwidth requirements and response times during
Figure 1 – 3: Vector Informatik GmbH
measured data acquisition and online calibration are rapidly increasing. Chassis and assistance systems now require
Links:
transmission rates of up to 100 Mbps. With the VX1000
Website Vector: www.vector.com
measurement and calibration hardware, a fast, direct, and
Product Information CANape: www.vector.com/canape
cost-effective interface to the ECU is available that com-
Product Information VX1000: www.vector.com/vx1000
municates with the ECU using the XCP on Ethernet stan-
Product Information CDM Studio:
dard ASAM protocol and can be easily integrated in the
www.vector.com/cdm_studio
housing in a space-saving manner using a POD (Plug-on-
Product Information vCDM: www.vector.com/vcdm
Device).
General Information Calibration Data Management:
For data exchange inside the team, solutions are in prepara-
www.vector.com/cdm
tion that will allow sharing of work results, measured values, parameter sets, reports, etc., via a trusted cloud virtually at the press of a button. The company network as well as a
Michael Vogel is employed at Vector Informatik GmbH as Business Development Manager responsible for vCDM.
cloud hosted by the tool manufacturer may be used for this. Whether in the office or on the test track, data can be read, changed, written back, and synchronized easily. Vision 2020: Calibrators Workbench Scalability paired with investment protection will also be at Figure 3: Equipped with a uniform user interface, the “Calibrators Workbench” will support engineers with a modular system of tools. It will provide similar methods and allow editing, analysis, and management of ECU-internal data. Users can easily develop and integrate their own expansions through reuse of standard functions.
5/2
the top of the priority list for customers for a number of years. Needed are tools and implementations that grow with requirements – from a single workstation to teams and finally to a enterprise-level solution. The specialists of Vector have named their vision of the next generation work environment the “Calibrators Workbench” (Figure 3).
5/3
stresses. The errors of a poor gear shift operation, for
bench tests and durability tests, or for evaluation purposes
example, expresses itself in typical vibration and jerky be-
– the managers there decided on an implementation strat-
havior, which is noticeable to the driver and passengers.
egy based on this Vector tool. The graphic display functions
Excessive thermal stresses associated with increased wear
are optimally tailored for measurement data applications
occurs when allowable friction values are exceeded during
and – an important prerequisite – CANape offers the op-
clutch operations.
tion of formulating company or project-specific evaluation algorithms using its internal programming language.
Proven Analysis Process is Pushed to its Limits
Analyze Large Quantities of Measurement Data Rationally and Flexibly On test benches and in durability tests, automotive OEMs collect important information on the behavior of vehicle components under realistic conditions. However, in view of the enormous quantities of data that are generated and their complex interrelationships, it is often a time-consuming process to subsequently identify and analyze the relevant data
The measurement data, which exists in various formats,
Calibration Tool as a Platform for Analysis and Graphics
comes from the CANape measurement and calibration tool
To obtain a usable analysis tool as rapidly as possible,
and from other data loggers. Previously, it was evaluated in
Daimler engaged Vector to implement the concept. Vector’s
a method where the first step was to process it in an inter-
task was to represent the evaluation algorithms Daimler
nal Daimler tool, and it was written to an Excel file (Figure
wanted as CANape scripts and to graphically prepare the
1). Then, an Excel macro would generate a graphic overview
results. The data mining functionality in CANape is now
on which the user could discern “trigger points” where
used to analyze the measurement data of interest. In an
errors occurred. Using these results, the relevant measure-
analysis of results, the tool lets the user visualize the
ment files were loaded in CANape, and finally the analysis
measurement file precisely at the location at which an error
points were displayed there. This approach was not only
occurred (Figure 2). CANape can be used as both the plat-
tedious; it was also burdened by other disadvantages and
form for executing the analyses and the platform for dis-
limitations. The Excel tools work very slowly, which is all
playing the results. The size limitation has been overcome,
the more challenging with large volumes of data. More-
and data volumes of up to 100 GByte can be processed
over, they also limit the maximum amount of data that can
effortlessly.
be processed, because the total number of lines in Excel
On the configuration side, the user selects the measure-
tables is limited, and the program only offers limited
ment data, chooses exactly what to study from a list of
graphic display options. Maintenance efforts for further
possible evalu-ations, e.g. upshifting or downshifting, and
development of the solution also had to be provided by
starts the analysis process (Figure 3). After completing the
Daimler.
evaluation, statistics are generated which provide a summary of the analysis. They show, among other things, that
Automated Evaluation by Data Mining
a 1-2 shift occurred a total of around 1,200 times (Figure 4).
Since CANape is already widely used at Daimler – whether
The heat entries can be displayed above other physical
in calibrating ECUs, logging measurement data in test
parameters in XY diagrams, for example. This results in dot
sets. To accelerate the analysis of measurement data in testing its automatic transmissions, Daimler AG relies on automated data evaluation by the CANape measurement and calibration tool from Vector.
The development of automatic transmissions at Daimler
Sprinter van. It attained a successful combination of the
began in the year 1960 with a 4-speed transmission, which
seemingly contradictory requirements of optimized fuel
would be considered a rather simple engineering design by
economy, driving fun and ride comfort, and in 2011 the
today’s standards. The rapid advancement of technological
transmission won the internal Daimler Environmental
development is attributable to a wide variety of new re-
Leadership Award.
quirements such as increased comfort needs, larger gear
5/4
spreads, lower fuel consumption, more powerful engines,
Automatic Transmission Requires Many Parameter
additional gears, etc. For example, the drive-off element
Optimizations
was changed, planetary gears and torque converters were
The extremely broad implementation range in the different
added, and in 1995 the first version with electro-hydraulic
models requires optimal calibration of ECU parameters to
transmission control was launched.
achieve the desired driving behavior. The path to product
The 7G-Tronic Plus automatic transmission represents a
maturity was accompanied by numerous test bench and
pinnacle of this development history. Designed in 2010, the
in-vehicle durability runs. Measurement data accumulating
7G-Tronic Plus can handle torques of up to 1000 Nm and
from daily testing is saved on servers, where it is available
can be implemented in a broad range of vehicles: from the
to development and calibration engineers. The challenge in
smallest rear-wheel drive vehicle of the C-class with a
evaluating and analyzing these large quantities of mea-
4-cylinder engine to the high-performance models of AMG.
surement data is to identify those data sets in which errors
The transmission is also used in the small variant of the
occurred, such as limit value violations or excessive thermal
Figure 1: The measurement data generated on test benches and in durability test vehicles are saved on the server and are available to calibration engineers for evaluation.
5/5
Analyze Large Quantities of Measurement Data Rationally and Flexibly
Figure 2: Data mining functionality is used to identify poor and good gear shift operations in a 2-axis diagram. This lets you quickly detect any limit value violations. Figure 4: Evaluation of traction pshift: initial assessments of the u durability run can already be made based on information in the predefined display windows.
clouds, where each point represents a shift operation. The
Flexible Adaptation of the Measurement Data
user can then recognize points lying outside of value limits
Evaluation
based on their position on the diagram. When a point is
The data mining functions of CANape allow Daimler test
selected, the related measurement file is loaded, and the
and calibration engineers to essentially perform an entire
user can generally visualize the value over a time axis in a
analysis of all of the measurement data and to see whether
Translation of a German publication in Elektronik automotive,
display diagram. The time segment in which this shift oper-
limit values were violated, or if undesirable events occurred.
10/2013
ation occurred is shown directly.
This is an important step for developers to attain more
Since the window contents are time-synchronized in
efficient use of the existing data material, and in the end it
Image rights:
CANape, all other windows show the specific contents, e.g.
lets them arrive at conclusions quicker and more precisely
Daimler AG
torques or engine speeds, which exactly match the time
in determining whether a specific ECU software level ful-
point at which the selected data point was measured.
fills the required maturity level.
Links:
In the windows, it is not only possible to show signal
The requirements for the analysis are subject to a continu-
Daimler AG: www.daimler.com
responses, but also limit value lines, e.g. the maximum
ally changing dynamic. Scripts may be modified either by
Vector Informatik GmbH: www.vector.com
tolerance values for frictional work and frictional power.
the end customer or by Vector as a service. If the language
Product information CANape:
Points lying outside of the limits indicate limit violations
tools of CANape are inadequate for any reason, other func-
www.vector.com/vi_canape_en.html
and errors in the shift operation. This makes it easy to iden-
tion libraries may be gene-rated from C code or Simulink
tify those gear shift operations that require closer exam-
models, and then they can be used as DLLs in CANape. This
ination.
makes it possible to implement any desired evaluations.
Erhan Tepe graduated with a major in Information and Communications Technology at the Polytechnic College of Reutlingen. After a two-year position as a programmer at a supplier, he obtained a Master’s degree at the European School of Business. In 2007, Mr. Tepe went to work for Daimler AG, where he is employed as a test engineer in automatic transmission testing. His work area involves test stand and vehicle testing in the validation of automatic transmissions. Andreas Patzer graduated with a major in Electrical Engineering at the Technical University of Karlsruhe. Focal points of his studies were measurement and control engineering as well as information and industrial engineering. In 2003, he moved to Vector Informatik GmbH in Stuttgart, where he is team leader for Customer Relations and Services in the Measurement & Calibration product line.
Figure 3: Data Mining user interface of CANape that was customized to the individual requirements of Daimler engineers.
5/6
5/7
cessing in the ECU is a high level of microcontroller perfor-
determine exactly where something was detected and
mance. On the other hand, whether the sensor data origi-
whether what was detected makes sense. In Figure 2, an
nates from a video or radar system has little impact on
“X” can be seen in the image at each point representing data
measurement instrumentation requirements – a high-per-
obtained by the sensor. Coordinates detected by the sen-
formance solution is essential for transporting the measure-
sor, such as the distance ahead and angle to the side, are
ment data. In evaluating and optimizing the algorithms,
converted to pixel coordinates of the video image in the PC.
the measurement instrumentation must be able to acquire all of the algorithm’s input and output variables and all
Approving and Optimizing Algorithms
necessary intermediate variables within the algorithm
If deviations occur while comparing detected objects with
without incurring additional controller load (Figure 1).
reality, then the algorithm needs to be optimized. This is
Serial bus systems such as CAN and FlexRay run into their
done by modifying the calibration parameters of the sys-
performance limits in terms of the necessary data through-
tem, and it requires that the calibration parameters be
put rates. Therefore, controller-specific interfaces such as
defined in the code such that they are located in RAM at
Nexus, DAP or Aurora are used to transport the large
runtime and can be changed by a write access. The mecha-
quantities of measurement data. It makes sense to rely on
nisms of the XCP measurement and calibration protocol [2]
established and proven standards to avoid having to devel-
are available for calibrating these parameters. At runtime,
op a separate solution for each technical measurement
the developer modifies the parameter values and gets im-
task. The VX1000 measurement and calibration hardware
mediate feedback on the effects. XCP is not limited to use
from Vector is ideal for this; it transfers the data from the
in the ECU. For example, the algorithm could also be run as
controller interface to a base module via a small PC-board
a virtual ECU in the form of a DLL on the PC. Calibrations
(plug-on device or POD), where it converts it to the stan-
and measurements are also made over XCP – which makes
dardized XCP on Ethernet; it then transfers the data
the PC a rapid prototyping platform.
stream to the PC at a high throughput rate [1].
What is the most convenient way to incorporate an XCP driver in a DLL? How are the input data linked to the DLL?
Verification of Driver Assistance Systems in the Vehicle and in the Laboratory Driver assistance systems acquire the vehicle’s environment via a wide variety of sensors. Warnings to the driver or (semi-)autonomous interventions in the driving situation are always made based on correct results of the object recognition algorithms. This article addresses the typical challenges that arise in verifying object data and testing the image processing algorithm. The XCP standard enables the necessary high data throughput in measurement and calibration.
Behind the wheel, humans acquire information about their
to detect objects such as road signs, parking vehicles, other
environment via their sensory organs – specifically their
participants in traffic, etc., and they initiate actions. To
eyes and ears. Signal processing in the brain interprets the
verify the sensor system, it may be sufficient to simply
collected information, decisions are made, and actions are
measure the results of the algorithm and compare them to
initiated. Decisions might include whether a space on the
reality. An example here is the distance measuring radar of
side of the road is large enough for parking or whether the
an Adaptive Cruise Control system: The sensor detects
distance to the car ahead needs to be adjusted. Driver
objects by return reflections of the radar beam. The ECU
assistance systems (Advanced Driver Assistance Systems
supplies range distance information for each object as co-
or “ADAS”) support the driver in making these decisions,
ordinates. In this case, it is not necessary to acquire all of
thereby enhancing safety and improving comfort and con-
the radar reflections in the sensor. However, all input vari-
venience as well as economy.
ables of the algorithm must be measured if the data is be-
Validating Sensor Data with Reality
In the case of a Simulink based development, the “Simulink
The ECU’s object detection results must now be verified
Coder” from MathWorks is used to generate the code for
against reality. Is the distance to the vehicle ahead on the
different target platforms from the model. The CANape
road actually 45.5 meters? To compare the sensor data
tool from Vector might be specified as such a target plat-
with reality, it is first necessary to acquire that reality. A
form. In the process of generating the code for CANape, an
camera, which is independent of the sensor system, records
XCP driver is automatically integrated. At the end of this
the driving situation. Developers can now quickly and reli-
process, there is a DLL with an XCP driver and an ECU de-
ably verify the object detection algorithms of their ECUs by
scription file in A2L format. Both are integrated in CANape,
comparing the objects detected by the ECU with the video
and the input and output ports of the DLL are linked to real
image. The CANape Option Driver Assistance measure-
data. At the measurement start, CANape transmits the
ment and calibration software from Vector is used to over-
measured sensor data as an input vector to the algorithm,
lay the object data on the video image. This lets developers
and the virtual ECU computes the results. The calibration
ing logged for later stimulation in the laboratory, for exam-
5/8
Access to Sensor and Algorithm Data
ple. In this case, over 100,000 signals with a data rate of
Driver assistance systems must be able to reliably detect
several megabytes per second would not be atypical.
the environment as a type of “attentive passenger”. Radar,
Image processing ECUs with video sensors are used for
ultrasonic and video sensors are very often used to provide
road sign detection systems or lane-keeping assistants. An
information to ECUs on the driving situation or the vehicle’s
algorithm analyzes the video images and detects road signs
environment. Complex algorithms process the sensor data
or lane markings. One typical requirement for data pro-
Figure 1: Acquisition of inputs and outputs, the environment and all data relevant to evaluating the algorithm. Display of all data, coordination of parameters.
5/9
Verification of Driver Assistance Systems in the Vehicle and in the Laboratory
independent of the ECU’s tasks. XCP is a standardized solution here; it is well-suited for all types of ECUs. Although driver assistance systems may involve special requirements in terms of data volume and performance, the use of existing tools based on XCP – such as CANape and devices of the VX1000 product line-up – is a convenient solution for ADAS ECUs too. They represent a natural step in the advanced development of existing solutions that can be Figure 2: Video image of the environment with objects detected by the distance measuring radar system and display of objects from a bird’s eye perspective.
seamlessly integrated into existing development processes – from the support of video data to the use of a rapid prototyping platform to develop image processing algorithms. Translation of a German publication in ATZ elektronik, 10/2014 Image rights: Vector Informatik GmbH
parameters are optimized in the same way as in a real
In a virtual ECU, stimulation involves streaming a logged
ECU. A C++ project supplied with CANape leads to the
video or signals from measurement files to an input port in
same result as manually written code.
CANape. In real ECUs, the physical inte rfaces must be con-
Links:
sidered. In video systems, for example, the video sensor sig-
Vector Informatik GmbH: www.vector.com
Stimulation with Sensor Data
nals can be routed to a monitor on which a logged traffic
Product information CANape:
Developers of sensor systems are confronted with two
situation is running. The ECU is always stimulated in the
www.vector.com/vi_canape_en.html
problems: >>Meaningful, realistic data from a sensor is often only
same way by using the same videos or signals – and this
Product information CANape Option Driver Assistance:
assures reproducibility of the data. Any changes in the be-
www.vector.com/vi_canape_en.html
available in the vehicle; the necessary environment is
havior of the algorithm are then exclusively a result of cali-
Product information VX1000:
bration and not of changed input vectors. In both virtual
www.vector.com/vi_vx1000_en.html
lacking in the laboratory. >>Achieving reproducibility of sensor data requires tremendous effort.
and real ECUs, stimulation is not limited to feeding data to inputs; necessary states and preconditions can also be set over XCP.
For these reasons, stimulation of ECUs with previously logged sensor data is a key component in development –
Summary
whether it involves a real or virtual ECU. The data may be
Optimal calibration of ECUs requires a great deal of effort.
written directly to the ECU’s memory, circumventing the
Measurement and calibration tools communicate with the
inputs, and the VX1000 System provides the necessary
ECUs, and this makes code instrumentation unnecessary.
bandwidth. Or the data may be transported into the ECU
Processes are defined for generating A2L description files
via its sensor inputs (Figure 3).
and much more. However, all of these activities are kept
Andreas Patzer graduated with a major in Electrical Engineering at the Technical University of Karlsruhe. Focal points of his studies were measurement and control engineering as well as information and industrial engineering. In 2003, he moved to Vector Informatik GmbH in Stuttgart, where he is team leader for Customer Relations and Services in the Measurement & Calibration product line.
Figure 3: Different input sources for stimulating a virtual video- based ECU in CANape. Real online data from the ECU via the VX1000 solution – from a camera or a logged video sequence.
5/10
5/11
Such a clearly defined approach creates process reliability and
vehicle attributes such as engine displacement, transmis-
increases data quality. The original files of the engineers who
sion type and emissions standard. The different product
maintain their work results in a Calibration Data Manage-
configurations require changes to the parameterization of
ment (CDM) system are subject to version management.
the ECU software, and they are referred to as “derivative
This means that the user can tell at a glance which param-
calibrations”.
eter sets have flowed into a specific variant and where they
Variant management provides mechanisms which ensure,
are being reused. This assures automatic updating of a new
for example, that all variants automatically get consistent
parameterization version in all relevant variants.
parameterization – thereby avoiding unnecessary redun-
Within the project, a quality and maturity level model helps
dant work. For parameters that depend on system attri-
in documenting changes for data integration and monitor-
butes, rules are used to describe dependencies. This guar-
ing the progress of the project. The CDM system takes a
antees consistent parameterization of all variants with
multi-stage approach to data integration. After all results
identical system attributes without additional work.
from the calibration engineers have been delivered into the system, it is able to resolve conflicts due to faulty or dupli-
Think Big, Start Small
cate parameterization by means of assigned parameter
A company’s adoption of a CDM solution rarely done in one
responsibilities and rules. The results can then be validated
big step, but frequently, solutions emerge for specific chal-
by the four-eye principle and checked for completeness.
lenges that come up in performing specific tasks. For in-
Only then is the data ready for consolidation for the next
stance, a calibration engineer might need assistance in dis-
data revision level and release for the next phase. This also
tributing work results to all calibration derivatives. Or a
facilitates cooperation with development partners, and it
project leader needs to resolve or avoid conflicts which oc-
assures access to correct data in different competency areas.
cur when calibration data is entered into the system by team members. The proliferation of such insular solutions
Calibration Data Management – A Puzzle Game no more Manage Complex Calibration Data at the Individual Workstation, in Teams and Throughout the Company In ECU development, short innovation cycles and high cost pressure lead to a distribution of work, in which the software development process is separate from the process of adapting it to its desired behavior in the vehicle. In today’s vehicles,
Efficiency by Intelligent Variants Management
makes a unified data management solution for the entire
Along with supporting calibration tasks by providing a
company increasingly all the more important. A central
clearly structured process, another core task of data man-
CDM solution can represent the entire process and sup-
agement is to productively manage large numbers of cali-
ports adjacent areas such as software development and
bration variants. A “calibration variant” represents a set of
validation (Figure 2).
Project Manager
Calibration Engineers
tens of thousands of such calibration data values must be determined and managed – and indeed for each individual vehicle variant. To avoid errors, quality standards are needed that have the same level as in the development of the actual software. This article discusses the requirements of tools for managing parameter values and presents a universal
Generate data sets Authorize calibration engineers Pre-calibration
Initiate calibration project
solution.
Fetch ECU program file
Hex
In the functional development of ECU software, high qual-
Today, around 60,000 parameters must be calibrated in
ity standards (SPICE, CMMI) must be maintained. The cor-
the ECUs of a diesel engine that conforms to the Euro-6
rect parameterization of the ECUs is as crucial as the cor-
emissions standard. Although ECUs in the chassis and car
rect functionality of the software in the ECU. Consequent-
body areas involve fewer parameters, they typically exhibit
ly, modifying parameters must meet the same quality
higher numbers of variants, and this also requires a dedi-
levels. This modification is referred to as “calibration” which
cated data management solution. In summary, the manu-
is essential for process adherence and quality assurance to
facturer of an automobile today must generate and man-
trace calibrations precisely and to ensure consistent pa-
age thousands of parameter set files.
A2l Calibrate online e.g. with CANape, INCA, ... Release ECU program for series
Calibration successful?
vCDM Deliver calibrated parameters
rameterization of every conceivable variant.
5/12
The trend toward shorter innovation cycles and more strin-
Improving Quality with a Clearly Structured Process
gent requirements for quality and efficiency make it essen-
The use of a special data management solution offers signifi-
tial to achieve a higher degree of reusability. It must be
cant help in the complex process of managing calibration data.
possible to reuse the software in many models and vehicle
It guarantees that the thousands of parameters are used in the
variants in developing electronic systems. Each variant in
correct variants in precisely defined combinations for hundreds
an ECU leads to a separate parameter set, and this in-
of vehicle calibrations. At the same time, each change must be
creases the number of parameter sets substantially.
precisely traceable for quality assurance purposes (Figure 1).
Check-in data det Generate reports
Data review and merge calibrated parameters
Figure 1: The CDM System offers a clearly defined process that leads to substantial quality improvements in the calibration of ECUs.
5/13
Calibration Data Management – A puzzle game no more
That is why it is helpful for the data management solution
Cooperation on a Team
Management). Efficient CDM systems exhibit high flex
For the calibration engineer, “CDM Studio” serves as an
to satisfy the specific requirements of a calibration engi-
ECU calibration is largely teamwork. These teams fre-
ibility and can be integrated in existing systems via
efficient tool for editing parameter set files (Figure 3). The
neer as well as those of a team and the entire company.
quently consist of members from different companies
automation interfaces, APIs (Application Programming
parameters generated in the ECU calibration process can
Such a scalable solution can be introduced and built up
(automotive OEMs, ECU suppliers and engineering service
Interfaces) or Web services. An integration with OSLC
be conveniently displayed, compared and edited. Due to
stepwise, while protecting investments.
providers). With increasing globalization and specializa-
(Open Services for Lifecycle Collaboration), for instance,
the many different import options it can be used through-
tion, efficient co-working of calibration teams is continually
makes it possible to implement universal traceability of
out the complete process – from software development in
Data Management for the Calibration Engineer
gaining in importance. It must be possible to distribute
changes.
MATLAB to online-calibration. CDM Studio supports all
In the ECU calibration process, the engineer first evaluates
work results quickly. Networking via e-mail and Internet is
the initial behavior of a system component using software
helpful - however - a lot of manual work steps are often
High Acceptance by Adapting to Specific Aspects
CANape, INCA, MARC and others.
tools (MCD tools) on the test bench or in the vehicle. The
required to exchange data between different systems. This
A CDM system has specific requirements when it is used
When multiple calibrators work on a team, solutions are
engineer then adjusts the parameters towards attaining
is a process that is time-consuming and prone to errors.
across different technical areas. That is because the work
needed for reliable data storage and data management.
the target behavior. However, this “online calibration” ap-
The data management system now gives teams the ability
procedures for calibrating a chassis controller differ notice-
“vCDM” is a database-supported platform for calibration
proach only represents part of the required work.
to automatically distribute the information. Integration of
ably from those for an engine controller. The different re-
teams and the entire company. The system avoids data
Frequently, it is also necessary to compare and edit the
the e-mail system informs all participants about data
quirements of the domain and the business organization
conflicts with work packages and assigns parameter re-
parameters for different vehicle variants without a direct
changes, new releases and software changes. This guaran-
result in different methodologies. When introducing data
sponsibilities. It detects and resolves parameter conflicts
connection to the ECU (offline calibration). This is the case
tees that the teams are working with identical data in a
management it is important to represent the different
and enables seamless tracking of data changes.
when parameters are “pre-calibrated” with values based
timely manner.
work modalities of the technical departments as ideally as
A large number of variants can be handled reliably by man-
on the requirements of software development, when the
Just as important as automated distribution is the avail-
possible, instead of prescribing a “standard process”.
aging dependencies, automatically computing parameter
results of similar prior projects are adopted, when values
ability of data at work sites with difficult network connec-
are copied from online calibration to different variants or
tions. Ideally, an engineer should be able to “check out” a
A Scalable Solution for all Uses
calibration variants with higher data quality, which can be
when numerical methods are used for model-based optimi-
calibration project from the central database on a laptop,
High levels of calibration data quality, process adherence
used in data mining and report functions for further quality
so that it is available in the local network for shared access.
and efficient variant management are the primary pre
and efficiency improvements. Finally, the integrated CDM
zation. For these tasks, the calibration engineer needs a tool with
values and reusing work packages. This leads to consistent
requisites for successful calibration projects. Vector offers
Studio is used to graphically display and process the cali-
a user interface similar to Microsoft Excel, in which param-
Data Management in the Enterprise
a scalable CDM product with solutions ranging from the
bration data. This results in a scalable solution with the
eters (rows) can be shown together with calibration vari-
A solution for data management is closely linked to the tool
individual calibrator to calibration departments and the
same look and feel, so that users can easily switch between
ants (columns), and any of the parameter values can be
chain for developing electronic systems. Changes to the
complete company-wide solution.
different applications.
edited. In addition, the tool must support the special re-
calibration data have a direct relationship to requirements
quirements of calibration (ASAM standard formats such as
management systems, change management systems and
CDF2.0, characteristic maps, diagnostic information).
many other ALM applications (ALM: Application Lifecycle
vCDM
Team Services CDM Studio Workplace Solution > Individual productivity > Fast introduction
5/14
commonly used measurement and calibration tools such as
Enterprise Solution > Roles / rights > Processes
Team Support > Sharing > Workflows
Figure 2: A scalable solution covers all requirements for process assurance, data quality and variants management.
Figure 3: CDM Studio shows the status of ECU calibration in a well-organized layout.
5/15
Conclusion In ECU calibration, tens of thousands of data values must be determined and managed for each individual vehicle
Stephan Herzog is employed at Vector Informatik GmbH as a Business Development Manager responsible for the Measurement and Calibration areas.
variant. To attain the required quality, it is necessary to have an assured process and universal tool support. It is also essential to consider the individual working methods of different departments and businesses. Wolfgang Löwl (Group Leader in Tool Development at Robert Bosch GmbH, Powertrain Area): “Together with
Andreas Patzer is employed at Vector Informatik GmbH as team leader in the Measurement & Calibration product line; he is responsible for Customer Relations and Services.
Rapid Control Prototyping for Functional Development of Dynamic Driving Systems Case Study
Vector, BOSCH developed a high-performance CDM system which fully met our special requirements. We have been using it successfully for 10 years now.” Outlook In the future, it will become increasingly more important to utilize the enormous quantities of data – not only to improve quality, but to also add value. For example, data mining algorithms and model-based calibration can be used to automatically generate new calibration data sets from the history of existing calibration data. These data sets can then be validated with special models. In the future, this will make it possible to shift increasing numbers of tasks from the vehicle to the office. Translation of a German publication in Automobil-Elektronik, 6/2015 Image rights: Vector Informatik GmbH Links: Website Vector: www.vector.com General Information Calibration Data Management: www.vector.com/cdm Product Information CDM Studio: www.vector.com/cdm_studio Product Information vCDM: www.vector.com/vcdm Product Information CANape: www.vector.com/canape
Michael Vogel is employed at Vector Informatik GmbH as Business Development Manager responsible for vCDM.
The Challenge
> CANape can be used to feed parameter values back into
To quickly validate control loops and functions on a real-
the MATLAB/Simulink development environment. > It is easy to acquire, condition and visualize data of the
time platform in a real system The complexity of the system network and of coordination
relevant control parameters with CANape. Users can
effort is increasing due to the growing number of chassis
conveniently navigate through the model and directly
control systems and driver assistance systems, as well as their mutual functional interactions. This means that vali-
access parameters and measurement values. > Quick reaction time in making modifications – and
dation of the functional model at BMW Group must be
without programming effort; design errors are found
performed on the real system early in the development
quickly.
process – while avoiding extensive changes to the ECU. The Solution Rapid Control Prototyping with “Bypass/Fullpass” solutions and real-time capable hardware To conduct tests of the control strategy in early development phases without existing ECU hardware, engineers need a Rapid Control Prototyping Platform. Here, BMW is using the VN8910 network interface with integrated realtime computer instead of a prototyping ECU. The input variables of the bypass model are read from the ECU via the VX1131 measurement and calibration hardware; the output variables are then computed in the VN8910 and sent back to the ECU. The “Bypass/Fullpass” model is created from MATLAB/Simulink. Internal model variables can also be measured and calibrated with CANape. The Advantages Fast, simple and cost-effective testing of different open and closed loop control methods Improved and dynamic test options benefit BMW developers with a higher level of functional quality: > BMW has a universal tool chain for the entire development cycle with CANape, the VX1131 system and the VN8910. > Low integration/migration effort, because the same control models are used over the entire development process. > The CANape MATLAB Integration Package makes it very easy to connect the model’s inputs and outputs to real variables. V2.0 | 2014
> Users can quickly generate, compile and link the code of the function algorithms. This produces A2L, DLL and MAP files that can be read directly into CANape. 5/16
www.vector.com/contact
5/17
the entire software process together. This ranges from
gines can only be used for a few drives before they need to
creating the code and developing the software to the com-
be replaced. On the other, the drives usually last less than
piler/linker run, A2L generation and the flash process.
ten seconds. Therefore, the key to success or failure of the optimization process lies in finding an extraordinarily ratio-
Optimal Results in just a Few Test Drives
nal method.
The engine calibrating process for drag racing is fundamentally different. Neither maintaining fuel economy nor sup-
Special Engine Controller Replaces Production Device
porting different engine or vehicle variants play a role here;
A highly efficient engine controller for drag racing comes
rather, all efforts are directed toward one goal: covering
from the maf-map-engineering company of Berlin, Ger
the approx. 400 meter distance as quickly as possible. Fur-
many. This company, founded on a passion for car racing,
thermore, the racing teams are not corporations with
offers a complete solution that gets maximum power out
strong financial backing; rather, they are typically private
of the engines. Its capabilities are illustrated by the fastest
individuals pursuing an expensive hobby. If faulty calibra-
VW Polo in the world, which trumps with 1,047 horsepower.
tion leads to engine destruction, a lot of money needs to be
Its performance is based on the ECU481 engine controller,
spent to buy a new one.
whose entire hardware and software was developed by the
No test stands are available for engine test runs either. For
company independently for ideal control of all components.
one, there are no suitable test stands due to the lack of
The software is created based on physical models, whereby
demand for this niche application. Secondly, it is not possi-
the Scilab modeling environment is used with an associat-
ble to optimize the engines at their maximum speeds of up
ed code generator for the functional layer. The basic soft-
to 10,000 rpm and up to 3.5 bar charge pressure in quasi-
ware is still manually coded in C.
static operation. The loads are so great that the engines
Since no test stand operation and only a few short test
could only withstand these speeds for a brief period of time
drives are possible, a primary focus is on reliable acquisition
(2 to 3 seconds per gear) without succumbing to heat over-
of all relevant parameters from the ECU via a cost-effec-
load.
tive interface. That is why the standardized measurement
The only feasible approach for the race teams is to acquire
and calibration protocol XCP on Ethernet was chosen. Early
In calibrating engine controllers for production vehicles, electronic developers typically work with engine test stands and
as many measurement variables as possible during the
on, a decision was made to search for a satisfactory
numerous test drives over different route scenarios. However, no such tools are available for special engine controllers
drive and then optimize calibration parameters based on
professional tool which lead the team to the CANape
used for drag racing. Using Vector’s CANape measurement and calibration tool enables an engine controller to be cali-
this information. However, this approach too necessitates
measurement and calibration tool from Vector.
brated for top performance without using a test stand while staying within a tight budget even under the continual risk
living with all sorts of limitations. On the one hand, the en-
Riding on the Razor’s Edge
Optimal Parameterization of an EngineController for Drag Racing
of destroying the engine after just a few test runs.
Anyone who has been to a weekend race event and seen
modified by mechanical rebuilding to prepare it for the
mid-class vehicles – with production engines with hundreds
demands of racing. While the rebuild represents one side of
of horsepower – covering a distance of a quarter mile
the coin, the other involves calibrating the engine controller.
(402.34 m) with deafening noise and incredible accelera-
All sorts of challenges must be mastered here, since the
tions, is very likely watching a drag race (Figure 1). Because
parameters of the production engine controller hardly har-
top engine performance is required very quickly in such ac-
monize with the modified engine any longer.
celeration races, a large share of development effort goes
Measuring and calibrating ECUs is a challenging but daily
into calibrating the engine controller. The art of the race
routine in the work of carmakers and suppliers involved in
team’s efforts is to achieve optimal results with a minimal
production development. While calibrators run various
budget. It is necessary to approach the stress limits of the
course scenarios with the engine on the test stand and in
engine so closely that it delivers maximum power without
the vehicle, they access internal parameters and ECU
being destroyed. Not only the driving but also the process
measurement variables via an A2L description file and find
of calibrating the engine can best be described as “a ride on
the optimal parameters. The complexity of this task signifi-
the razor’s edge.”
cantly increases due to a whole series of constraints. On the one hand, numerous engine and vehicle variants need
5/18
Optimally Calibrated Engine Controller Enables
to be considered, and different emissions standards need
Maximum Power
to be met. At the same time, the ECU must be imprinted
In a personal endeavor, it takes a great deal of passion and
with an OEM-specific driving behavior. All optimizations
enthusiasm to spend the time and money it takes to build
are also subject to the premise that certain fuel economy
and maintain a vehicle for drag racing. The key item here is
limits must be observed. Engine calibrating is simplified by
the engine. A production engine is purchased, which is then
the fact that calibrators and software developers control
Figure 1: To optimally calibrate the engine controller, calibration parameters are adjusted in real-time during the test run based on acquired measurement results.
5/19
tion of this process are especially beneficial here. Code is generated from Simulink models using the Real-Time Workshop code; after compiling and linking, it is run as a DLL in CANape. At runtime, during the test drive, the algorithm in the DLL obtains measurement data from the engine controller, uses it to compute optimal parameters and autonomously calibrates the parameters in the controller via XCP mechanisms and CANape (Figure 2).
Model-Based Development and ECU Calibration With XCP and CANape Case Study HOERBIGER
Since the effort required to develop separate application models for all parameters would be excessive, many pa-
Figure: HOERBIGER
rameters are still adjusted manually. After the drive precise analysis of the logged measurement data with CANape tion of corrections (Figure 3). In addition, the tool helps to reduce the number of necessary test drives to a minimum. New parameter values are derived from the results, which developers either set online in the controller’s RAM or implement as new model values before the next code generation. More evidence that the approach works well and is on the rise is provided by the 2010 King of Germany (KOG) event, Figure 2: Besides being used to develop a control algorithm that is fed concrete data from ECUs, bus data, analog data, etc., CANape also covers other applications such as online computations during a measurement.
in which a vehicle with an engine controller from maf-mapengineering took first place in the class of front-wheel drive vehicles. Meanwhile, this success in the general classification has been noted by other industries. Contacts have already been made with boat racers who are looking for a comparable solution for their race boats: an engine con-
Automated Parameter Optimization in Real-time
troller optimally calibrated for this specific field of applica-
Key ECU parameters are calibrated by the maf-map-engi-
tion with efficient measurement and calibration capabilities.
neering specialists or the individual racing team; they are not calibrated after the test run, but during the test run
Translation of a German publication in Elektronik automotive,
itself – in real-time – based on acquired measurement
4/2011
results. Because of the extremely short test driving times it is impossible for the driver to mentally note all of the data,
Image rights:
derive meaningful decisions from it and still send the right
Lead Figure and 1: Dr. Bernd Seydel
values to the ECU. CANape functions that enable automa-
Figure 2 and 3: Vector Informatik GmbH Links: Homepage maf map engineering [only German]: www.maf-map-engineering.de Homepage Vector: www.vector.com Product Information CANape: www.vector.com/canape Product Information CANape CANape Option Simulink XCP Server: www.vector.com/simulinkxcpserver
Figure 3: CANape visualizes the various parameters and offers convenient calibration options
5/20
Andreas Patzer After training to become an electronics technician in the IT field, from 1986 to 1993, Andreas Patzer studied Electrical Engineering at the Technical University of Karlsruhe, where he specialized in measurement and control engineering as well as information technology and industrial automation. After graduating, Mr. Patzer worked in the communications industry. In 2003, he joined Vector Informatik GmbH in Stuttgart, where he manages the interface between the customer, development and sales as a Business Development Manager for the Measurement & Calibration product line.
The Customer
The Advantages
HDM (HOERBIGER Drivetrain Mechatronics), a division of
Simulink models can be visualized and parameterized con-
HOERBIGER Corporation, is a highly regarded clutch expert
veniently and efficiently
in the global automotive industry. It specializes in the devel-
The CANape Option Simulink XCP Server is ideally suited
opment of dual-clutch mechatronic systems for sports cars,
for analyzing model behavior: > The standard XCP protocol enables use of the same
high-end sedans and heavy truck applications.
CANape configuration over the entire development The Challenge To conveniently test the behavior of Simulink models In developing software for the second generation of a dual-
process. Regardless of whether the model, a rapid prototyping platform or the ECU is connected. > To test the model as realistically as possible, logged
clutch transmission, engineers convert the existing, manu-
measurement data can be fed into the model as input
ally written C code to MATLAB/Simulink models (Re-Engi-
parameters at runtime. > It is easy to visualize the measurement data and modify
neering). The code is then automatically generated from the models and integrated directly in an AUTOSAR RTE.
parameters in the various CANape windows.
Each software module can be simulated in Simulink.
Object-specific model instrumentation is unnecessary.
However, existing MATLAB Scopes visualization options
> Calibration Data Management with CDM Studio makes
are inadequate in conducting detailed data analysis. The
it easy to edit and manage parameter set files in the
process of optimizing parameters is also time-consuming
model. Users can copy and merge different parameter
and rather inconvenient, requiring modification of values in
sets, download to the Simulink model and save
the MATLAB Workspace or generation of specific GUI
parameters in different formats, e.g. as an M-script in
elements.
MATLAB format. > Simulation results are available in MDF format. This
The Solution
enables direct comparison with measurement data from
CANape as a user interface for parameterizing and visual-
the vehicle and from the manual or automated evaluation
izing Simulink models and internal ECU data The simplest way to interface CANape with the model in
in CANape. > The solution is scalable: in simulations that are especially
Simulink is with the Simulink XCP Server. Users have the
computationally intensive, processor loads can be
same options available here as in connecting to an ECU:
distributed to 2 computers.
drag & drop selection of measurement and calibration parameters from the description file and visualization in display and calibration windows. The necessary A2L description file is generated from the Simulink model at the press of a button; this enables read and write access to parameters in the model without requiring additional instrumentaV2.0 | 2011-03
reveals any critical issues and enables rapid implementa-
tion of the model.
www.vector.com/contact
5/21
In the “Simulink XCP Server” option for the CANape mea-
(Figure 2). Simulink users will feel right at home in the
surement and calibration tool from Vector Informatik
familiar model representation that does not require con-
GmbH, an XCP driver is integrated into the Simulink model.
version. In the model, a modified parameter is passed
As a result, the model is treated like a virtual ECU. The ef-
directly to the XCP Server via XCP. It adjusts values in the
fort required to integrate the XCP driver is minimal: a single
Simulink blocks and in the base or model workspace; this is
block from the Simulink CANape library is dragged and
equivalent to manually setting the values via the MATLAB
dropped into the model. Settings of the XCP transport lay-
console.
er – such as the host name and server port – can be config-
The function developer can change parameters of a full
ured in the block’s dialog. They are necessary, since the
Simulink model, or those of one or more subsystems, easily
“XCP-on-Ethernet” protocol is used to interconnect the
and conveniently. This provides a way to test and optimize
measurement and calibration tool with the Simulink model
a Simulink model with different parameter sets. CANape
(Figure 1).
supports different file formats here. Once the model has
After this parameterization step, the XCP Server is ready
attained the desired maturity level, the relevant parame-
to use. The model’s A2L description file is generated from
ters are saved to a parameter set file. The parameter set
the block’s dialog. A virtual address is assigned to each
management feature of CANape’s CDM Studio (Calibra-
Simulink object there. This is how the Simulink XCP Server
tion Data Management) is used to compare individual
explicitly implements address-oriented XCP operation for
versions created during model optimization and merge
the Simulink objects. The user then selects objects in
parameter subsets or work packets to obtain optimal set-
CANape in the usual way – by their names. An object’s ad-
tings for the entire model. These settings may be exported
dress is read-in from the A2L and is sent as information to
in the form of a MATLAB M-script so that they can be used
the XCP Server in the model. This means that for data
directly as a new version level in the MATLAB/ Simulink
objects in the XCP Server, the address in the A2L file is only
development environment (Figure 3).
leveraged for identification because the application’s data objects do not yet have a real ECU memory address. After
MATLAB/Simulink as Time Master
instrumenting the model, using it with CANape is easy and
Simulink models may run either slower or faster than real
efficient because it is possible to generate a CANape
time, depending on their complexity and computer perfor-
project directly from the configuration of the block’s dialog
mance. This makes time stamps from Simulink indispens-
Efficient Analysis of Model Behavior in ECU Function Development
in Simulink and start CANape with the created project.
able. With each simulation step in Simulink, the associated
The focus in ECU function development is always on finding the best possible control algorithms and parameter combi-
Numerous Measurement and Calibration Functions
nations. A new solution now offers users a single measurement and calibration tool with universal application – from initial model design to the production level ECU.
5/22
time stamp is sent via XCP. Consequently, variations in the amount of the time needed for the simulation steps are
Accelerate Model Optimization
irrelevant. Each simulation step corresponds to one time
The user visualizes the desired measurement parameters in
unit, regardless of how much real time is needed for it. In
the measurement and calibration tool CANape – indepen-
the process, Simulink acts as a time master, and the
dent of the hierarchical organization and without further
measured data sent out by the model can be visualized in
In the framework of model-based software development,
Communication via XCP-on-Ethernet
instrumentation of the model. It is possible to display any
CANape at simulation speed. Depending on the complexity
application functions are checked in an iterative process.
The ASAM protocol XCP (Universal Measurement and Cali-
of the input or output variables of the model blocks and
of the model, sensor data from a one or two hour real test
This involves repeated runs of the model in Simulink from
bration Protocol) has become established as the preferred
have their time responses displayed in graphic form.
drive may be computed in just a few seconds or in minutes.
The Mathworks. Depending on the results, the developer
solution for measuring and calibrating applications in
Parameters and signals can also be conveniently displayed
If a user wishes to simulate especially large and complex
may add function blocks by drag-and-drop operation from
ECUs. This approach gives application engineers conve-
and calibrated right in the visualization of the model
models, standardized communication with XCP-on-Ether-
libraries. These blocks are parameterized either directly in
nient access to measurement data and parameters in the
the function block with a numeric value or by defining a
ECU via standard bus systems at runtime.
parameter and its value on the MATLAB console. To modify
An ASAM standard A2L database (ECU description file)
an existing parameterization, the same steps are executed
provides all the information needed to access parameters
again, either by looking for a block in the model and chang-
and signals in the ECU. It contains descriptions of relevant
ing its value, setting the parameter and its new value on
data objects within the ECU’s software, such as character-
the MATLAB console, or modifying an M-script and running
istic values (parameters, characteristic curves, maps) and
it. To visualize the signal responses that occur when the
measurement variables. The database also connects the
model runs in Simulink, the user instruments the model by
object names to their memory addresses in the ECU and pro-
attaching scope blocks to each of the desired signals.
vides conversion rules for physical interpretation of the raw
Use of the standardized XCP measurement and calibration
data. Using such a database, measurement and calibration
protocol gives the developer a considerably more user-friend
tools can be used to acquire signal data or tune parame-
ly way to efficiently manage parameters and measure sig-
ters as desired by the user. Only a protocol driver is needed
nals from the Simulink model without instrumentation.
in the ECU; it enables memory access at the ECU’s runtime.
Figure 1: Model objects can be measured and calibrated conveniently and with high performance using an XCP Server integrated in the Simulink model and an automatically generated A2L file.
5/23
Efficient Analysis of Model Behavior in ECU Function Development
Translation of a German publication in Automobil-Elektronik, 4/2009 Image rights: Vector Informatik GmbH Links: Product information CANape: www.vector.com/vi_canape_en.html André Ebner is employed at Vector Informatik GmbH as Technical Team Leader for the “Measurement and Calibration” product line.
Figure 2: Efficient analysis of model behavior by convenient navigation and quick access to objects of the Simulink model in CANape.
Andreas Patzer is employed at Vector Informatik GmbH as Business Development Manager for the “Measurement and Calibration” product line.
Wojciech Przystas is employed at Vector Informatik GmbH as a Software Development Engineer for the “Measurement and Calibration” product line.
net enables better computing performance, since two separate computers are used. The simulation results may be analyzed either manually or through automation. In this process, an instance checks the received results and makes a parameterization decision. Serving as an instance is the CANape script language or an external software program that CANape controls via one of the existing automation interfaces. Data from logged test drives may be fed into the model as an input vector at runtime to stimulate the model with real data. The function developer analyzes and optimizes system behavior under comparable constraints. This eliminates the need for real, cost-intensive test hardware entirely. Summary The implemented access to MATLAB/Simulink models via XCP in a measurement and calibration tool simplifies the work of function developers considerably. For example, the model is automatically instrumented via XCP, and this replaces the very tedious process of manual instrumentation. As a universal front-end for measurement and calibration tasks, CANape offers added convenience in the test phase of models in Simulink. When XCP is used as a universal protocol over the entire development process, this reduces overall process complexity. The function development proFigure 3: Overview of actions in CANape and their effects on the model in Simulink
5/24
cess is simplified and accelerated, since just one protocol, one description file, and one tool are used for all measurement, calibration, and stimulation tasks.
5/25
TriCore or XC2000, access is via the Device Access Port
where new changes are saved in a First In, First Out (FIFO)
(DAP) interface; for the PowerPC devices from Freescale or
buffer in RAM. The measurement is initiated by one of up to
V850 E2 processors from Renesas, access is via the Nexus
256 different software triggers, and the contents of the
Class 2+ interface. In this method, the ECU software initi-
mirrored RAM are “frozen”. Based on the measurement
ates a RAM copy function according to the cycle time of the
configuration, the signals are read out from the mirrored
various ECU tasks. The measurement signals must be
RAM in the base module for measurement data and are
preconfigured over XCP on Ethernet. The mapping of signal
sent to the measurement and calibration tool over XCP on
names and RAM addresses is described in an A2L file (ASAM
Ethernet (Figure 2).
standardized ECU description file for signal-oriented RAM
Advantages of the Nexus Class 3 solution: >>The maximum measurement data rate of 30 Mbyte/s is
accesses). Once all measurement signals have been copied, the signals are transmitted to the base module for mea-
a factor of 30 times larger than with Nexus Class 2+ and
(Figure 1). This concept is referred to as “Online Data
600 times larger than with XCP on CAN. >>The CPU is typically not loaded by the measurement.
Acquisition” (OLDA).
>>All PWM drive signals can be measured at the 100 kHz
surement data according to the existing debug interfaces
Compared to CAN, the measurement data rate and sam-
sampling rate without any problems.
pling rate are improved by a factor of 20, i.e. 0.5 to 1 Mbyte/s of measurement data can be acquired with a sampling rate
The disadvantage of this solution lies in the fact that signif-
of 10 – 20 kHz. The copying operation loads the CPU approx.
icant effort is involved in connecting the POD with its 25
4 % at 1 Mbyte/s.
pins to the microcontroller, and it must process a very large raw data stream of 100 Mbyte/s.
Data Trace Concept for Nexus Class 3 – Current
High-speed Measurements for Electric and Hybrid Vehicles New Measurement Concepts Enable High Data Rates and Frequent Sampling Times In the development of electric and hybrid vehicles, in particular, the requirements for instrumentation used to measure internal ECU signals are very high. Nonetheless, measurement data rates of up to 30 Mbyte/s and the necessary sampling rates of 100 kHz can be achieved with the latest generations of microcontrollers and an intelligent measuring instrumentation solution. The ECU’s CPU is not loaded here.
The drives of electric or hybrid vehicles are generally con-
pins and the POD is 10 cm. Communication between the
trolled by pulse-width modulation (PWM) signals. The ad-
measuring instrumentation module and the test PC is over
vantage of PWM technology is that it incurs very low power
XCP on Ethernet in accordance with the MCD-1 XCP stan-
losses at power switches, because they only need to be
dard from ASAM. The physical connection is made by a
operated in two operating states: fully conducting or fully
standard CAT-5 Ethernet cable. Essentially, two different
blocking. The frequency of the PMW signals typically lies in
measurement methods are distinguished: the “RAM copy
the 10 – 20 kHz range, and in exceptional cases up to
method” and the “data trace method.” They are presented
100 kHz. Maximum sampling rates of only 1 kHz are achiev-
in this article, together with their advantages and disad-
able for internal ECU signals when XCP – a widely used
vantages, based on current microcontrollers and new
standardized measurement and calibration protocol for ve-
microcontrollers that will be available soon. The different
hicle development – is used together with communication
data trace methods refer to two types of 32-bit microcon-
over the CAN or FlexRay bus system. PMW signals cannot
trollers that are primarily used in powertrain ECUs and
be acquired in this method.
their successors: Freescale PowerPC (primary market:
That is why the debug and data trace interfaces are used
USA) and Infineon TriCore (primary market: Europe).
Freescale PowerPC
Data Trace Concept for Next Generation Microcontrollers
Most devices of the current Freescale PowerPC series sup-
The main disadvantage of the Nexus Class 3 solution will be
port the data trace method of Nexus Class 3. In this case, the
eliminated in next generation microcontrollers, because the
developer configures one or two monitoring windows with
pin count has been reduced from 25 to 5. However, the
a maximum total size of 512 kByte in the ECU RAM. Any
measurement data rate and sampling rate will remain at
changes within these monitoring windows are transmitted
the same unchanged high level. This data trace solution will
to the POD via Nexus Class 3 without any additional CPU
also be supported by future processors from the Infineon
load. Transmission rates for raw data of up to 100 MByte/s
and Freescale companies. The raw data stream von
are possible over the High Speed Serial Link cable. The ad-
100 Mbyte/s must still be processed.
vantage of this concept is that the base module for measurement data always contains a consistent mirrored RAM
Data Trace Concept for the Current Infineon TriCore
of the ECU’s RAM. An ECU software trigger interrupts the
A concept comparable to Nexus Class 3 may also be used
data flow within the measurement data base module,
for DAP. This involves reserving a 256 kByte memory range
for fast access to ECU variables. These interfaces can vary
5/26
significantly depending on the type of microcontroller that
RAM Copy Method
is implemented. The measurement hardware is interfaced
The RAM copy method is a generic method, and can be
to the ECU over a “Plug-On Device” (POD). The maximum
used for current and future generations of 32-bit microcon-
allowable distance between the microcontroller’s debug
trollers from various manufacturers. For the Infineon
Figure 1: Data flow concept for measurement signals by the RAM copy method and Nexus Class 2+ interface
5/27
High-speed Measurements for Electric and Hybrid Vehicles
nals often reach their limits in terms of data rate or sampling rate. The sampling rates of up to 100 kHz that are necessary for electric drive systems can be implemented for existing and future microcontrollers using the VX1000 measurement and calibration hardware from Vector. Over the course of this year, new controller generations will be available from Freescale and Infineon, which can perform their tasks with a data trace that requires significantly fewer connection pins. In combination with the high-speed VX1131 measurement module from Vector – which will be available in the second half of 2012 – they will enable measurement data rates of 30 Mbyte/s without CPU loading. Figure 2: Data flow concept of measurement signals by the data trace concept and Nexus Class 3 interface
In the case of Infineon, DAP2 with finely granulated signal filters in the microcontroller make it possible to reduce the raw data stream from 100 to 15 Mbyte/s, which permits the use of very cost-efficient measurement hardware to achieve high data rates. When used with the ASAM-stan-
of the ED-RAM (Emulation Device RAM) for measurement
One advantage lies in its higher raw data transmission
dardized XCP on Ethernet as the PC interface, the measure-
data acquisition. In contrast to the 100 MByte/s of the
rate, which is now 20 MByte/s in contrast to the previous
ment and calibration hardware is also ideal as a flexible
Nexus Class 3 concept, the trace transmission rate for raw
5 MByte/s. This is attained by the higher frequency of
and powerful bypass solution with short latency times.
data must be limited to 5 MByte/s; just 4 pins suffice in-
160 MHz at the DAP interface instead of the previous
stead of 25 pins. A maximum of four RAM monitoring win-
80 MHz and by a new type of three-line concept, which
Translation of a German publication in Hanser Automotive,
dows may be configured. They must be configured so that
permits parallel transmission on two lines.
5-6/2012
there is no overrun of the trace data. Generally, this per-
The greatest improvement to the DAP2 interface is that it
mits monitoring of just 10–20 kByte of memory instead of
now lets users set up hardware-based data trace filters
Links:
512 kByte and measurement of signals in this memory
with extremely fine granularity. This significantly reduces
Vector’s tools for ECU calibration:
without processor loading. Signals outside of these trace
the transmission of unnecessary data trace information
www.vector.com/vi_calibration_solutions_en.html
monitored memory areas can be measured by the RAM
from the microcontroller to the POD. Despite the maxi-
Product information VX1000:
copy method.
mum measurement data rate of 10 Mbyte/s, it is only nec-
www.vector.com/vi_vx1000_en.html
Advantages of the Infineon DAP data trace solution: >>The maximum measurement data rate of 3 Mbyte/s is a
essary to process 15 instead of 100 Mbyte/s of raw data
Product information CANape:
(Figure 3). Due to the considerably reduced requirements
www.vector.com/vi_canape_en.html
factor of 3 larger than in the RAM copy method. >>The microcontroller is not loaded by the measurement.
for processing the measurement data, cost-optimized measuring instrumentation can be used for DAP2.
>>All known PWM drive signals can be measured at a 100 kHz sampling rate without any problems.
Summary Many aspects of modern drive concepts for vehicles with
Data Trace Concept for Future Infineon controllers
pure or hybrid electric motors make it necessary to develop
In the next generation of microcontrollers, Infineon is also
new strategies for measurement data acquisition. Existing
offering the latest generation Device Access Port (DAP).
measuring instrumentation concepts for internal ECU sig-
Alfred Kless After graduating from the Technical College of Esslingen with a degree in Electrical Engineering, Alfred Kless initially worked for ALCATEL where his roles included team leader for software development and business development of test systems. Since May 2004, he has been employed at Vector Informatik in Stuttgart as Business Development Manager for the product lines “Measurement & Calibration” and “Network Interfaces.”
Figure 3: In the data trace concept, fine grain filters reduce the raw data stream to 15 Mbyte/s over the DAP2 interface.
5/28
5/29
Analyzing AUTOSAR ECU Software with XCP Convenient Debugging by Extending the AUTOSAR Basic Software When debugging in an environment of networked ECUs, debuggers are often of limited use, especially if errors only occur sporadically or in the test vehicle. In such cases, the proven measurement and calibration protocol XCP offers useful services. Described in the following is a method for using XCP to monitor processes in the AUTOSAR basic software (BSW) and in the software components (SWCs). Certain features must be added to the basic software for these measurement purposes. Specialized extensions for the analysis tool allow for efficient debugging and easy evaluation.
Many test tools available today support the approach of
Besides physical conditions that restrict debugging in the
testing individual ECUs using a remaining-bus simulation.
vehicle, there is another factor as well: some errors only oc-
They let users verify required functions in an early stage
cur sporadically. Determining the causes of sporadic errors
and independent of the ECU network. This results in very
is not always easy in the laboratory either.
application level. Moreover, time stamps are necessary to
grated in the existing BSW configuration chain for conve-
reconstruct the error history in the analysis.
nient configuration of XCP and the remaining modules.
XCP in AUTOSAR 3.x Projects
Creating an A2L File
The AUTOSAR 3.x standard does not specify any mecha-
It is a challenge to create the A2L file using the supplemen-
nisms for remote debugging. For years now, however, the
tal information noted above. To accomplish this task, the
“Universal Measurement and Calibration Protocol” (XCP)
test engineer needs a defined process and suitable tools.
has been successfully used to measure and calibrate ECUs
Due to the many different configuration options of the
in vehicle development, and it covers the requirements cit-
AUTOSAR BSW, it is advantageous to generate the A2L file
ed above very well. XCP provides mechanisms for reading
and therefore any changes made to the BSW configuration
and writing variables via bus systems. Based on DAQ (Data
are accounted for in the A2L file.
Acquisition) lists, multiple variables can be measured con-
The A2L file needed to measure the data flows between
sistently and with a common time stamp. Dynamic DAQ
software components (SWCs) can be generated with the
lists make it possible to reconfigure the data records to be
RTE generator from Vector (Figure 2). This enables moni-
read out during the measurement. They offer a way to
toring of Intra- and Inter-ECU communication and mea-
optimally utilize the available bandwidth of the communi-
surement and stimulation of the connected sender/receiver
cation bus.
ports. The A2L file is generated based on the RTE configu-
Typically one or more A2L files are used in conjunction with
ration which is created with DaVinci Developer. In addition,
XCP measurements. An A2L file contains information on
the RTE generator inserts changes needed for the mea-
the relevant measurement objects in the ECU. Required for
surement in the RTE code.
each of these objects is information such as memory ad-
To track the data flow in the modules beneath the RTE as
dress, data type, symbolic interpretation and conversion
well (Figure 2), Vector also offers an A2L generator for
rules. Along with the description of parameters for commu-
measuring parameters in the basic software. The A2L file is
nication between the XCP Master (e.g. analysis tool) and
also generated based on the configuration. To make it eas-
the XCP Slave (ECU), an A2L file also contains a hierarchi-
ier to find the measurement objects, they are stored hierar-
cally structured representation of the measurement ob-
chically in a directory structure within the A2L file.
jects. XCP is a powerful protocol for debugging with its many different ways to access internal ECU variables and
Acquiring Measurement Data
convenient configuration via an A2L file.
Often, the test engineer can already localize the modules
The XCP protocol is implemented in a dedicated BSW
responsible for the error and define the data for analysis
module, which however is not defined in the AUTOSAR 3.x
based on the error pattern. First, the XCP Master estab-
standard. It is linked to the relevant AUTOSAR communica-
lishes a connection to the XCP Slave. After the connection
tion drivers for the bus system being used (CAN, FlexRay,
has been established, the first data can be read out from
Ethernet, etc.) (Figure 1). The XCP driver is seamlessly inte-
the ECU. This is generally information such as the version
high quality at an early stage of software development.
6/0
However, testing options are reduced considerably when an
Requirements for Debugging
ECU is installed in a test bench or in the test vehicle, or
To find the cause of an error, the values of various software
when a function is distributed over several ECUs via a
variables are typically checked. It is also important to
network. It is no longer so easy to localize the errors that
simultaneously check the variables of multiple software
occur.
modules in reference to a trigger point. This lets users mon-
The causes of this are: >>An ECU is installed in such a way that it is difficult to
itor inter-module consistency conditions. Key examples of
access. >>No more connection terminals are available for debug-
interdependent, e.g. the AUTOSAR “Bus State Managers”
ging. >>The debuggers for the different ECUs do not condition
engineer must determine which application requests
the data uniformly. >>The test tools cannot be housed in the vehicle.
necessary to observe causative chains beyond module
this are the “manager modules” whose state machines are and “Communication Manager” (ComM). Similarly, the test caused the ECU to enter the measured states. It is also boundaries, e.g. to trace a signal path from bus level to
Figure 1: MICROSAR – the AUTOSAR basic software from Vector – contains modules for measuring internal ECU data via XCP
6/1
Analyzing AUTOSAR ECU Software with XCP
sentation of values rather than with raw values. To allow
has its own communication protocol, which is not XCP-com-
this, the A2L file must contain assignments of raw values to
patible. The functions of the two modules DBG and DLT
symbolic names – similar to Enums familiar from the C pro-
can, however, also be implemented with XCP. Vector al-
gramming language. CANoe handles the display of symbolic
ready offers this in its AUTOSAR 3.x solution (Figure 1).
values. This type of representation is excellently suited for
Figure 2: Generating A2L files based on the ECU configuration
High-performance Access to Measurement Data
sented in code using Enums. This method can be applied to
The described mechanisms provide a powerful debugging
any desired variable, e.g. to symbolically indicate whether it
tool for any ECU – regardless of the AUTOSAR version. The
is loaded with a substitute value or initialization value.
developer can track and analyze processes in the ECU very conveniently using proven XCP tools such as CANoe and
Debugging in AUTOSAR 4.x Projects
CANape from Vector. Use of the VX1000 measurement
The AUTOSAR 4.x standard satisfies the requirement for
and calibration hardware is recommended for measuring
debugging options in the software by implementing the
large quantities of data at rates of up to 5 MByte/s with
modules DBG (Debug) and DLT (Diagnostic Log and Trace).
minimal effects on ECU execution time (Figure 4). In this
These two modules utilize mechanisms that are similar to
case the ECU is accessed via the debug interfaces JTAG or
those provided by XCP. The main task of the DBG module is
NEXUS.
The Option AMD (AUTOSAR Monitoring and Debugging)
to read ECU data, which is buffered inside the ECU and
the test engineer selects the A2L file matching the ECU’s
extends the functionality of CANoe with an XCP Master, in
sent to a PC for further evaluation by the developer. Com-
version level and starts the data measurement.
order to dynamically address multiple Slaves. Users can then
munication with the PC is done by a dedicated communica-
In case of errors that are difficult to reproduce, a quick
change the XCP configuration during a running measure-
tion protocol. Similar to the A2L file for XCP, in the DBG
analysis of the data might not be possible while the mea-
ment. With Option AMD, the State Tracker (Figure 3), Graphic
approach a description of the data to be measured is gen-
surement is running. In these cases, data loggers with inte-
and Data analysis windows are also available for variables
erated. This generation is based on the module descriptions
grated XCP functionality or software tools with an XCP
measured over XCP. Similarly, the XCP variables can be ac-
of all BSW modules to be measured.
Master store measurement values in the vehicle for longer
cessed from the integrated CAPL programming language
The DLT module has the task of routing the error messages
time periods. In subsequent analysis of the data, XCP
or from test automation, enabling automated analysis.
and warnings generated at runtime to a PC. These mes-
Master tools are used such as CANoe – the widely used
The measurement values acquired from the ECU can be
sages are generated by the BSW modules DET (Develop-
simulation, analysis and test tool from Vector.
analyzed directly during the measurement. The XCP Master
ment Error Trace), DEM (Development Event Manager)
must offer suitable mechanisms for this purpose. Therefore
and by software components of the application. DLT also
numbers, version identifiers, etc. Based on this information,
Analyzing Measurement Data
CANoe includes definable trigger conditions in the State
To test ECUs independent of the communication bus that
Tracker Window, e.g. freezing the window contents for quick
is used, the XCP Master must support various bus systems
analysis when a certain measurement value is reached. In
such as CAN, FlexRay or Ethernet. Furthermore, in debug-
addition, CANoe enables complex evaluations of measure-
ging it may be necessary to measure and evaluate the data
ment values via a CAPL program.
of multiple ECUs in parallel. Therefore, it is advantageous
If saved measurement values are to be evaluated in detail,
to have an analysis tool that is also multi-master capable.
it is easier for the developer to work with symbolic repre-
Figure 3: The CANoe State Tracker window offers users convenient visualization of internal ECU data acquired with XCP.
6/2
observing state machines, whose states are often repre-
Figure 4: The VX1000 easurement and calibration m hardware from Vector enables acquisition of large quantities of data with minimal effects on ECU execution time.
6/3
How does XCP Work?
However, if the measurement should be started imme-
For years now, the Universal Measurement and Calibra-
diately after ECU initialization, the measurement con-
tion Protocol (XCP) has been successfully used to mea-
figuration must be stored in the ECU’s non-volatile
sure and calibrate ECUs in vehicle development. XCP is
memory. This so-called Resume Mode enables measure-
a global standard that was standardized by the Associ-
ments immediately after the ECU start.
ation for Standardization of Automation and Measuring Systems (ASAM) in 2003. While the CAN Calibration
Published in the special edition of Hanser automotive in
Protocol (CCP) is limited to the CAN bus, XCP enables
November 2011.
the exchange of the Transport Layer. It supports buses such as CAN, FlexRay, Ethernet, USB, etc. and is based
Image rights:
on a Master/Slave principle. Using a Command Transfer
Vector Informatik GmbH
Object (CTO), the XCP Master sends commands to the XCP Slave over the bus; then the XCP Slave responds with a Data Transfer Object (DTO). XCP can be used to
Dipl.-Ing. (FH) Patrick Markl is teamleader of the Concept Development team for the Embedded Software product line at Vector.
read and write values in the ECU’s memory. The XCP Master periodically requests measurement data from the XCP Slave (polling) or has the data sent to it when specific events occur (XCP Events). Which mechanism is used depends on many factors. Measurements with XCP Events utilize bus bandwidth better than with polling. However, it is necessary to modify the ECU code to trigger the XCP Events; this is not necessary with polling. Similarly, XCP Events can already be provided at certain points in the application code during development. Aside from a slight execution time overhead, the XCP code behaves passively. When XCP Events are needed for the measurement, the XCP Master activates them during the measurement. Another advantage of XCP Events is their event-driven output of multiple data with a common time stamp. This lets the developer precisely track certain processes in the software and check whether variables are consistent with one another. With XCP Events, the test engineer can perform measurements independent of the state of the communication bus. In the case of polling, measurement commands must be received from the Master, and so bus communication is absolutely necessary. This requirement is omitted with an Event. However, the XCP Slave must provide a buffer that stores the measurement data until communication with the XCP Master has been restored. Due to the severely limited resources within the ECU, continuous buffer storage is understandably impossible. Two buffer strategies are conceivable here. First, there is the linear buffer, which only accepts measurement values until it is full. The other version is a ring buffer, in which the oldest entries are overwritten by new values. Before a measurement can be executed via XCP Events, the XCP Master must configure the Slave driver suitably. This is done by a series of commands. First, the XCP Master establishes a connection with the XCP Slave, then it transfers the necessary configuration.
6/4
Dipl.-Ing. (FH) Stefan Albrecht is Senior Product Management Engineer for CANoe/CANalyzer Option AMD.
Figure 1: AUTOSAR layers model
Plug and Play Solution for AUTOSAR Software Components The interfaces defined in the AUTOSAR standard enable an easier assembly of the ECU application out of components from different suppliers. However, the process of software development is delayed, because an additional step is required to combine the individual components into the overall software. The use of exchangeable software components reduces the number of these overall integrations, because it is possible to exchange individual software components in flash memory without linking the entire project. This accelerates software development at each of the individual suppliers.
Post-build: Software Adaptations after Linking
cess does not impair the remaining ECU software. This is
AUTOSAR defines a post-build method for the basic soft-
done either online on the ECU using a flash bootloader, or
ware that makes it possible to modify the behavior of cer-
offline using a suitable HEX editor with subsequent trans-
tain BSW modules after compiling and linking. This involves
fer into the ECU (Figure 2). SWC exchanging is normally per-
storing the configuration data in flash memory, separate
formed by the SWC supplier, but it can also be performed
from the BSW module code. This means that the data can
by the overall integrator. By saving in overall integration
be replaced at runtime without having to recompile and
effort, suppliers can realize shorter development cycles:
link the ECU software.
Coding – Exchanging – Testing – Optimizing (Figure 3).
The AUTOSAR standard does not define any comparable
The overall integrator initially generates a software image
post-build method for the SWCs of the application soft-
of the entire ECU and makes it available to the SWC sup-
ware, and so every modification – even to just one SWC –
pliers. Then, the suppliers only need to create a new version
requires compiling and linking of the entire ECU software.
of their SWC, place the binary of it at the correct location
However, there is a way to reduce the number of complete
in the overall software image, and they can then begin to
integrations. In the following, we present how an SWC sup-
test their SWC right away. To prevent the SWC versions
plier can exchange individual SWCs of the application soft-
from drifting apart excessively, the overall integrator gen-
ware directly in flash memory, which reduces integration
erates new ECU software images at regular intervals with
overhead.
updated versions of all SWCs. There are no limitations with regard to which SWCs may be
The AUTOSAR ECU software is subdivided into three areas:
Distributed Software Development
What is the Procedure for Exchanging SWCs?
exchanged. However, the decision about this must be made
basic software, runtime environment and application
The modular AUTOSAR architecture makes it easier for soft-
When exchanging an SWC, the existing SWC is replaced by
during the ECU planning phase, because special consider-
(Figure 1). The basic software (BSW) is the basic frame-
ware suppliers to specialize in specific applications and compo-
an updated version directly in the ECU’s memory. This pro-
ations must be observed in implementation and memory
work that provides the application with the resources of
nents, e.g. basic software, vehicle dynamics, engine manage-
the microcontroller by means of drivers and abstraction
ment, etc. As a result, it is not unusual for an ECU’s software to
layers. The Runtime Environment (RTE) serves as the inter-
consist of modules and components from different suppliers.
connecting layer between the application and the basic
The individual parts are supplied as either source code or pre-
software. The RTE abstracts the communication between
compiled binary files, and they are combined into complete,
application sections and thereby enables transparent data
executable ECU software at the responsible ECU producer
exchange beyond ECU boundaries as well. For this purpose
during an overall integration. In turn, all SWC suppliers get the
the RTE provides interfaces to the application and the
resulting software image for their further development steps.
basic software. In contrast to the BSW, whose static
However, this method is very time-consuming, and it slows
modules can be used unchanged in different ECUs, the RTE
down software development. On the one hand, the ECU
is individually generated for each ECU and only supplies the
producer must perform a tedious overall integration for
interfaces that are actually needed. The application con-
each new version of an SWC. On the other, the SWC sup
sists of software components (SWCs), which implement
plier must wait for the integration results to be able to test
ECU functionality in the form of what are known as Run
its application in interaction with the other ECU software.
nables.
The frequent waiting periods lead to considerable extra effort, particularly in early development phases.
6/6
distribution.
Figure 2: The exchangeable SWC is released in the memory image (above) and is transferred to the ECU’s flash memory.
Figure 3: Exchanging of SWCs accelerates an SWC supplier’s software development.
6/7
Plug and Play Solution for AUTOSAR Software Components
Reserving Memory for Exchangeable SWCs
ment as an alternative. This environment only needs to ser-
code of the runnables (Figure 5). As a result, this code may
time. This handle points to an indirection structure of the
In today’s software development, overall integration typi-
vice the interfaces called by the SWC (Figure 4).
be changed as desired, without shifting the addresses of
RTE, the so-called Component Data Structure (Figure 6).
cally involves linking the SWC program code without speci-
In both of these variants, after compiling and linking the
the runnables in the static area.
Stored in this structure are the addresses of all port inter-
fying memory mapping parameters. In the case of ex-
SWC supplier obtains a binary file which, along with the
Whenever an SWC is compiled and linked, the symbolic
faces of the SWC. Therefore, the SWC does not need to
changeable SWCs, the SWC supplier must perform linking
SWC, also contains the code for the software environment.
jump targets of the runnables are replaced by the actual
know the addresses of the RTE port interfaces. The Com-
based on specific memory mappings. During linking, both
This additional code is irrelevant for the later exchange of
addresses or offsets. Therefore, the RTE does not need to
ponent Data Structure is described in the Contract Phase
the RTE and the SWC expect one another‘s interfaces at
an SWC and is removed. This results in a binary file of the
know the actual addresses of the runnable functions.
Header file of each SWC.
the addresses stored in the ECU memory. To assure this,
SWC to be tested, in which the jump targets are already
the ECU memory is subdivided into multiple partitions that
stored at the correct memory addresses.
Calling Port Interfaces from an SWC
Constraints for Exchanging an SWC
Analogous to the call of the runnables by the RTE, in the
To make it possible to exchange SWCs as described here, certain constraints must be satisfied. >>During the process of replacing an SWC, port interfaces
are exclusively reserved to the individual SWCs. To determine the partition sizes, an estimate is made of how much
How does Exchanging of SWCs Work?
opposite direction the runnable functions must call the
memory the SWC’s individual runnables are expected to
After updating an SWC in flash memory, it must still be
port interfaces provided by the RTE. If the SWC supplier
require. Initially, this increases the memory requirements
possible for the RTE or other runnables to call the runna-
uses a complete software environment with BSW and RTE
must not be added or removed. However, additional port
for the application. However, this only applies to the devel-
bles contained in the SWC. During compiling in a complete
from the complete integration (See section “Software en-
interfaces may be allocated in the RTE generation for
opment period. Partitioning can be omitted in the final soft-
integration, the linker replaces the symbolic jump targets
vironment for compiling and linking an SWC”), no further
ware for production use to reduce memory requirements.
stored in the RTE by the actual (real) addresses of the run-
measures are required, because all jump targets are known
Generally, only complete flash pages can be erased, in the
nables within the SWC. Because these addresses remain
at the linking time.
SWC, because the RTE can call all runnables known at
simplest case one or more complete flash pages are re-
unchanged within the RTE when an SWC is exchanged, it
However, if a minimal software environment is used, the
the time of RTE generation. If runnables are removed
served for each SWC. However, if the SWC is significantly
must be guaranteed that the runnables of an exchange-
port interfaces of the RTE are located at other addresses
during development, or if new ones are added, the RTE
smaller than one flash page, and the resulting fragmenting
able SWC are always stored at these memory addresses
than those of the overall integration when the SWC is cre-
must be modified accordingly, and an overall integration
is unacceptable, multiple SWCs may be assigned to one
for every compiling and linking operation. This condition
ated. This results in incorrect addresses being stored when
flash page. In this case, however, it must be assured that the
can be satisfied by suitable compiler and linker instructions
linking the SWC.
rest of the flash page content is not changed during the ex-
that allocate fixed, manually assigned addresses to the in-
To ensure that calling of port interfaces from the SWCs
which requirements the individual SWCs will place on
change of the SWC with the flash bootloader or HEX editor.
dividual runnables, for example. However, it is very likely
operates correctly, two AUTOSAR features are used with
the ECU. This relates to hardware resources, on the one
that the memory requirement of the runnables will grow
exchangeable SWCs: Object Code and Multiple Instantia-
hand, but also to the additional mathematical libraries
Software Environment for Compiling and Linking an SWC
over the course of ECU development. For this reason, a
tion. With this combination, the RTE passes the so-called
To compile and link their SWCs, suppliers need a software
memory area must be reserved within the SWC. To set up
Instance Handle as a parameter to each runnable at run-
environment that resolves all SWC dependencies to the
this reserve, the SWC supplier uses compiler instructions to
nated to prevent incompatibilities due to different
called interfaces. Ideally, this environment would be the en-
subdivide the SWC into a static area and a changeable
compiler versions and options.
tire, runnable ECU software – including the BSW and appli-
area.
cation – which is also used in the overall integration. In its
The static area contains the area for jumps into the SWC.
basic methodology, this variant represents a complete inte-
This always remains the same, even if the implementation
gration; however, the integration takes place at the SWC
of the functionality changes. The SWC’s runnables are
supplier.
modified to achieve this. They no longer contain the specif-
The set-up of such a software environment usually takes
ic application code, rather just a function call. The so-called
much effort, and is not always possible. Therefore, the
runnable functions that are called here are located in the
SWC supplier can independently create a minimal environ-
SWC’s changeable area and contain the actual functional
Figure 4: With exchanging SWCs, a minimal software environment is used for linking instead of the entire software environment.
6/8
Figure 5: By subdividing the SWC into a static area and a changeable area, the runnables lie at fixed addresses and can be called without re-linking the RTE.
future extensions. >>The number of runnables must not change within an
must be executed. >>In the planning phase, it is already necessary to define
needed and scheduling of individual runnables. >>The tool chains of individual suppliers must be coordi-
Figure 6: An instance handle is passed to the runnables when they are called. This gives the runnable functions access to the port interfaces of the RTE.
6/9
Outlook The application example presented here – with multiple SWC suppliers and one overall integrator – is not the only conceivable application case. Exchangeable SWCs can also simplify bypassing of SWCs, because the instrumentation necessary for bypassing can be conveniently applied to the ECU by a exchangeable SWC. If the SWC will then actually be tested on the ECU, the instrumentation can be replaced once again by the non-instrumented SWC. Exchangeable SWCs represent a powerful tool that can support and accelerate the development of ECU software. So far, preparation of an SWC and memory mapping still needs to be performed manually. However, there are plans to automate much of this process by configuration. Translation of a German publication in ATZ elektronik, 01/2012 Image rights: Figure 1: AUTOSAR development cooperation with extensions by Vector Informatik GmbH Figure 0 & 2-6: Vector Informatik GmbH Alexander Zeeb, Vector M.Sc. is Software Development Engineer in Concept Development for Embedded Software at Vector Informatik GmbH in Stuttgart
Accelerate Your Embedded Development!
Standardized Basic Software for CAN, LIN, FlexRay, Ethernet, J1939
Take advantage of scalable software modules which are being used successfully worldwide. > Benefit from the Vector AUTOSAR solution
> Update your ECUs securely with the Flash
with smart extensions > Combine software components individually and
Bootloader on a high level of process reliability > Boost your efficiency with our customized
specifically for your projects > Save on development time by using a perfectly tuned tool chain
consulting and development services Find out more: www.ecu-software.com
Vector supports you in your development work with ECU software, configuration tools and services.
6/10
Vector Informatik GmbH | Germany · Austria · Brazil · China · France · India · Italy · Japan · Korea · Sweden · UK · USA | www.vector.com
Figure 1: Division of ECU
AUTOSAR ECU Development Process Using DaVinci and MICROSAR from Vector
evaluation and the EV-ECU were then connected using a
ECU Development Process Testing
CAN communication network. (Figure 2, “Local CAN”).
Here is a summary of the tests we carried out with a focus
To evaluate software reusability, the software assigned to one of the two AUTOSAR ECUs was divided again and ap-
on the ECU development process with AUTOSAR. >>Differences from legacy ECU development processes
plied to another AUTOSAR ECU (Figure 7). This implemen-
>>Division of roles between automobile OEMs and
tation process was compared to the implementation process of commonly reused software, to evaluate software
suppliers >>Tool chains
reusability with AUTOSAR.
>>Data definition file format
English Translation of a Japanese Technical Article from Mitsubishi Motors Corporation AUTOSAR is a group paving the way for the standardization of software platforms across Electronic Control Units (ECU). Its activities have gained momentum in recent years. In order to find out how AUTOSAR could best be applied to ECUs, we – Mitsubishi Motors – joined forces with our supplier, Mitsubishi Electric, to test the development process and evaluate the tool chains relevant to the implementation of AUTOSAR software components on ECUs. For evaluation we used the EV-ECU of the i-MiEV electric car. Here is an overview of the project.
AUTOSAR
confusion and disruption. This is why we joined forces with
As the number of on-board computers (ECUs) in automo-
Mitsubishi Electric, our ECU supplier, and Vector Japan Co.,
biles increase along with their functionality, there has been
Ltd. to test the AUTOSAR ECU development process and
an increase in software implementation. As a result, the
verify the development environment (tools) as a prepara-
Europe-based AUTOSAR has been gaining attention as the
tion for implementing AUTOSAR software components.
leading platform for the standardization of basic software
This project also covers evaluation of software reusability
specifications. This standardization covers basic software
with AUTOSAR.
modules e.g. for I/O access, CAN communication and the operating system. Furthermore, the standardization in-
AUTOSAR Evaluation Overview
cludes XML formats for exchanging configuration data.
For this project, we evaluated the EV-ECU, the main control ECU for the i-MiEV electric car. We decided to extract
6/12
Preparing for AUTOSAR
and use a part of Mitsubishi Motor’s model-based soft-
As it is not yet clear how AUTOSAR will affect the existing
ware from the EV-ECU. To carry out the evaluation, the ex-
ECU development processes and development environ-
tracted software was divided and assigned optimally to
ments of automobile OEMs and suppliers in Japan, imple-
two ECUs using microcontroller evaluation boards (Figure
menting AUTOSAR without careful thought may cause
1). The AUTOSAR ECUs designed for the purpose of this
Figure 2: Overview of vehicle network
6/13
AUTOSAR ECU Development Process Using DaVinci and MICROSAR from Vector
This project evaluated the processes listed below. We have
Vehicle Network Design
summarized the details of the workflow and testing crite-
On the vehicle network of an i-MiEV, a gateway ECU was
ria, as well as the results for each process. The development
set up where the EV-ECU was located, and a local CAN
and implementation environment can be seen in table 1. >>Vehicle system design
communication network was constructed using the modi-
>>Vehicle network design
We used Network Designer for the CAN communication
>>ECU application software design
network design (Figure 3). The CAN communication data
>>ECU software system design
was exported as a system description file in ARXML for-
>>ECU software detailed design
mat. As far as the communication network design is con-
>>Coding/ Implementation
cerned, the design method remains unchanged except for
fied EV-ECU and the AUTOSAR ECUs (Figure 2).
the tool and data transfer file format. In addition to the Vehicle System Design
ARXML format, Network Designer also offers various other
A certain system requirement specification was created for
formats such as DBC and FIBEX which could be used in-
the evaluation project. We designed a system focusing on
stead of the AUTOSAR format. As network design also
coordination between the EV-ECU and the extracted soft-
takes the entire vehicle into consideration, the process is
ware. The evaluation included the allocation of functions to
carried out by the OEM.
each ECU, the network configuration and choosing suitable AUTOSAR BSW. The system requirement specification has
ECU Application Software Design
been revised according to the evaluation results. The allo-
We edited the software extracted from EV-ECU using
cation of functions to each ECU was realized by assigning
Simulink®. According to the software model’s inputs and
software components (SWC) using the AUTOSAR method.
outputs, we defined the AUTOSAR compliant ports/inter-
It depends on the OEM and the project whether to define
faces and runnable entities.
the SWC and BSW configuration during the vehicle system
In terms of software reusability, the SWC input/output
design, or during ECU design. Since we were dealing with a
port and data configuration require caution, especially with
The model’s software source code and the SWC Descrip-
allocated to each ECU. Next, the System Description file
small-scale system and with BSW provided by the specific
regard to the collection of data and configuration of the
tion file were automatically generated using Real-Time
generated from the network design was imported and the
port. If the data does not match other SWC port configu-
Workshop® Embedded Coder™. In this evaluation project,
CAN communication data and SWC input/output data
rations when reusing SWC, the port configuration will have
the ECU application design was carried out by Mitsubishi
were mapped. DaVinci Developer features an automatic
to be changed (Figure 4). On the other hand, creating a
Motors. For series projects the division of roles should be
data mapping function, which is extremely useful when
port for each data makes the SWC configuration too com-
discussed before design.
dealing with large amount of data. The data configured by
software vendor, we chose the former option.
Figure 4: Points to note in terms of SW-C reusability
DaVinci Developer for each ECU is exported as an “ECU
plicated and is therefore not recommended. For SWC ports in line to be reused, it is important to review the port con-
ECU Software System Design
Extract of System Configuration” file in ARXML format.
figuration beforehand.1
The ECU software system design involves the allocation of
As the network design is frequently being updated with re-
Regarding the interaction of tools, it should be taken into
SWC to ECU and designing the ECU input/output data.
gard to the ECU development process, it is important for
consideration that several tools might change the Soft-
We used DaVinci Developer™ (Figure 5) for this purpose.
the Runtime Environment (RTE) design tool that the Sys-
ware Component Description file (SWC Description).2
First, the SWC Description file generated from Simulink®
tem Description can be simply updated and that the con-
was imported into DaVinci Developer and the SWCs were
tent of such updates can be easily verified.
1 In the latest AUTOSAR release 4.0, these problems are reduced since it is possible to explicitly define the mapping between port data. 2 Therefore, the tools need to support a roundtrip and must not overwrite the data created by another tool.
The ECU software system design was carried out by Mitsubishi Motors. For small-scale development projects (such as closed projects with ECU units), it may be efficient for the supplier to carry out the design. However when designing software partially or designing a cooperative control with multiple ECUs, it is better for the OEM to do the design. By mapping the communication and SWC data, the OEM can verify the consistency of the data in advance. This is useful, as inconsistency of data can lead to unnecessary work between the OEM and supplier. ECU Software Detailed Design ECU software detailed design involves the configuration of ECU device drivers and design of OS and ECU basic func-
Table 1: Development and implementation environment used for evaluation
6/14
tions (CAN communication, error diagnostic functions, Figure 3: Network Designer™
Figure 5: DaVinci Developer™
etc). The design uses the ARXML-format “ECU Extract of System Configuration” files gene-rated above.
6/15
AUTOSAR ECU Development Process Using DaVinci and MICROSAR from Vector
written to ROM. We used an IAR compiler for compiling. In the past, the codes were generated manually by hand coding. In contrast, AUTOSAR enables the usage of configuration tools and automatic code generators for coding. As is the case with legacy methods, coding/ implementation is carried out by the supplier. Functional Testing We equipped an i-MiEV with the AUTOSAR ECUs we designed and ran vehicle tests (Figure 6). As the functions formerly processed by one ECU are now distributed to several ECUs, there was some delay in communication between the ECUs. Nevertheless, we were able to onfirm that the Figure 6: Vehicle testing
car was controlled correctly by the AUTOSAR ECUs. Testing Reusability We then tested the reusability of SWCs. By assigning the
Specific design details include the allocation of Runnable
SWCs to an additional ECU (they were assigned to two
Entity to OS tasks and the configuration of the relevant BSW
ECUs during ECU development process testing) and chang-
parameters. We carried out the configuration in this case
ing the assignment pattern (Figure 7), we estimated the
using DaVinci Developer, GENy and DaVinci Configurator Pro.
process and man-hours needed in porting the SWCs. We
The ARXML-format “ECU Configuration Description” file
were then able to compare the legacy design and the de-
describes the specific configuration of the basic software
sign according to the AUTOSAR method.
ECUs and data mapping with CAN communication data
Evaluating Tool Chains
modules and is shared between the involved tools. As ECU
are both easy to do by using the tools. This has not been the
As tool chains influence the quality of the software greatly,
software detailed design is dependent on the hardware
Here are the tasks involved in porting the SWC: >>Redesigning the network
case until now: adapting application software interfaces
it is important to discuss issues thoroughly with the sup
configuration, it is carried out by the supplier.
>>Assigning SWCs to ECUs
usually took much time and effort.
plier. Considering the tool dependence, it makes sense to
>>ECU software detailed design
Regarding the detailed design of ECU software, it is possi-
use tools from the same vendor throughout the entire de-
ble to reduce the configuration settings when carrying over
velopment process. The tool chains evaluated in this project
Redesigning the network is necessary for both legacy and
parts of the existing configurations. As a result, there is a
can be seen in figures 8 and 9. The pink areas show the work
automatically generated by DaVinci Configurator Pro and
AUTOSAR methods and the processes do not differ by
great potential for reducing the time and effort that usual-
carried out by the OEM and the light blue areas indicate
GENy. This code is compiled along with the static code of
much. The application software and SWC interface require
ly goes into adapting interfaces and designing middleware.
the work carried out by the supplier.
the basic software into the executable code, which is then
no modification in porting the SWCs. Assigning SWCs to
Coding/Implementation The configuration code for the basic software modules is
Figure 7: Evaluating reusability and ease of porting
6/16
Figure 8: ECU development process with AUTOSAR (Part 1)
Figure 9: ECU development process with AUTOSAR (Part 2)
6/17
From network design to AUTOSAR RTE/BSW/OS detailed
Translation of a publication in the Japanese Vector Journal
design and code generation, Vector offers tools encompassing the entire process. As the tool chain is pre-estab-
Image rights:
lished, there is consistency and uniformity in the data through
All figures: Mitsubishi Motors Corporation
out the process, increasing reliability in development. The tools could be improved by expanding the compatibility
Literature:
of data exchanged with the most commonly used tools
www.autosar.org
from other companies. As model-based development with AUTOSAR has proven to be a valid development method
Links:
for the future, we hope this issue will be prioritized.
Homepage Vector: www.vector.com
Also, GUI-based software design is efficient in the design
Information on Vector’s AUTOSAR products:
phase, but it is not suitable for comparing and verifying the
www.vector.com/autosar
design data. An additional function to export the data designed by each tool in table format would be desirable. The process of testing the communication signal’s configuration parameters and the transmission and reception of the signal was very complicated. This process would be
Author: Yuichi Kamei Mitsubishi Motors Corporation Electronic Control System Development Electronics Engineering Dept. Development Engineering Office
much more efficient if the data could be exported in table
Developing a Driver Library for Engine Controllers with AUTOSAR Complex Device Drivers (CDD) Case Study FAW
The Customer
The Advantages
The FAW Group Cooperation, the “First Automotive Works,”
A domain-specific driver library that can be extended by FAW. > All basic software is configured and generated with a
with its headquarters in Changchun, is the largest Chinese manufacturer of diesel engines, passenger cars and
single tool: Both the AUTOSAR standard modules and
medium- to heavy-duty buses and trucks. FAW produces
the special drivers for engine control are configured with
over 2.5 million vehicles annually and is one of the first
format.3
Chinese OEMs to implement AUTOSAR.
DaVinci Configurator Pro. > The driver library can be extended or modified with the DaVinci Configurator Kit, e.g. when new sensors or
Summary
The Challenge
By testing the ECU development process using AUTOSAR,
Developing a driver library for engine controllers with
we were able to gain an understanding of the workflow and division of roles. We were also able to clarify the necessary mutual consultation between OEMs and suppliers for each process. With AUTOSAR, the OEM can take over the
AUTOSAR Complex Device Drivers (CDD).
department that maintains and extends the library.
FAW is developing a new generation of its engine control-
Different vehicle projects have access to the central
lers and is consistently implementing AUTOSAR basic soft-
library and configure it for their specific engine control-
ware in this process. This software will be implemented as
designing process usually associated with the supplier side.
one platform which is capable of controlling both gasoline
Furthermore, there is room for optimization in overlapping areas such as ECU software system design, where both OEM and supplier should be more flexible in the future. Regarding reusability, we found that this goal can be easier reached with AUTOSAR than with legacy methods. How ever, we focused solely on the sender-receiver port format
actuators are introduced. > Reduced administrative effort by having a central
lers with DaVinci Configurator Pro. > The process and interfaces conform to AUTOSAR
and diesel engines. Since AUTOSAR does not define any
specifications: The control algorithms for engine control
suitable drivers for engine controllers, FAW wants to extend
are still developed with Matlab and Simulink and are
their AUTOSAR driver library. They would like to be able to
implemented as AUTOSAR software components
select the necessary sensors and actuators from a toolkit
(SWC). They interface with the AUTOSAR basic soft-
and configure them in the desired quantities and types
ware and engine-specific drivers via the RTE.
with the help of a universal tool chain.
for the SWC input/output, therefore the reusability for server-client port formats still needs to be evaluated.
The Solution
Through the evaluation project, we were able to establish
Configuration and code generation of the engine-specific
the technical details to some extent. In the future, we will
drivers with the existing AUTOSAR tool chain from Vector.
actively exchange information and opinions with suppliers
Vector implemented the drivers for controlling engine-spe-
and tool software vendors to put in place a framework for
cific sensors and actuators as what are known as Complex
the introduction of AUTOSAR at Mitsubishi Motors, from
Device Drivers (CDD). To configure the drivers, the relevant
the introduction process to implementation.
Basic Software Module Description (BSWMD) files were generated with the DaVinci Configurator Kit. The code gener-
Afterword
ators were also created with the DaVinci Configurator Kit.
We received great support for this evaluation project.
DaVinci Configurator Pro reads the BSWMD files and links
Compilers were kindly provided by IAR Systems, and micro-
the associated code generators. This lets it configure the
controllers by Renesas Electronics Corporation. Though we
drivers for the engine controller and the AUTOSAR basic
were not able to realize their offer for this evaluation, an
software.
offer from Fujitsu Semiconductor Limited for collaboration was greatly appreciated. And of course, Mitsubishi Electric’s cooperation and Vector Japan’s tool software were invalufor their support.
6/18
V2.0 | 2011-05
able. We’d like to take this opportunity to thank everyone 3 In the latest generation of the tool chain, Vector provides according functions to compare the design data.
www.vector.com/contact
6/19
6/20
6/21
6/22
10 ye ars auTosar E x PLOiTATiOn
On-bOard diagnOstics Meets aUtOsar
Development of a Reference System for AUTOSAR ECUs and System Studies
As powertrains become more electric, the number of on-board diagnostics relevant Electronic Control Units (ECUs) continues to
AUThORS
Case Study
grow. Vector provides a summary of the on-board diagnostics functions integrated in the AUTOSAR basic software (BSW) and which use cases they support.
For vehicles with combustion engines, increasingly more stringent emission limits have been set in recent years. To continue meeting these limits over years of vehicle operation, an on-board diagnostics (OBD) system must monitor components and systems to ensure fault-free operation. Typically, three classes of ECUs are defined for each vehicle. The Master ECU takes on the role of collecting, conditioning and supplying central data and it controls warnings to the driver. Primary ECUs are ECUs that acquire local data in their fault memories and communicate with the scan tool, while Secondary ECUs only report to a Primary or Master ECU. Functions for monitoring components and systems are subdivided into two
categories: Major Monitors are relevant for systems that have a direct effect on emission values (for example fuel and exhaust recirculation systems). Comprehensive Component Monitors check the systems that are needed for the Major Monitors or systems that affect emissions indirectly. They include functions related to battery regeneration while braking the vehicle, battery management and climate control systems.
AUTOSAR
Compact reference system for ECU and system develop-
playing a leading role in the introduction of AUTOSAR. Its
ment with AUTOSAR. > “Sandbox” to develop functional extensions of the
mature E/E processes enable efficient development of AUTOSAR-based ECUs.
AUTOSAR basic software or the application > Simple benchmarking of different system states
The Challenge
> Clearly organized user interface for manually stimulating
To develop a reference system with multiple networked ECUs based on a specified development process. The system
system states > Easy to extend the reference system with real ECUs
must support CAN, J1939 and LIN based on the Vector
> Minimal effort for executing regression tests after
AUTOSAR basic software MICROSAR. The reference system should support key parts of the OEM AUTOSAR functional content and the following tasks: > Validate correct implementation of the specifications and of the OEM’s predefined development process
oBD FuncTIons as parT oF The auTosar BsW
The rapid spread of electrically assisted drives leads to a growing number of Primary ECUs that have Comprehensive Component Monitor functionality. AUTOSAR defines the OBD functions that should be implemented in the DCM (Diagnostic Communication Manager), DEM (Diagnostic Event Manager) and FIM (Function Inhibition Manager) modules. To a high degree, they reference definitions in the OBD standards and directives. The concrete implementation and ❶ The OBD-specific extension of the DCM module contains nine additional services configuration, for October 2013
DIpl. Ing. olIver garnaTz is Product Manager in the Embedded Software Area at Vector in Stuttgart (Germany).
The Advantages
A successful European heavy-duty vehicle producer that is
functional changes or updates to the AUTOSAR basic software > Good expandability based on modular structured hardware and software > Validated and optimized development process
> Verify system behavior
example calibration strategy and relation to UDS (Unified Diagnostic Services) fault memory, must be defined by software suppliers in cooperation with the OEMs. The DCM module implements OBDspecific services, ❶. Moreover, OBD requests are either prioritised over UDS requests, or they are processed in parallel. The DEM module also contains various OBD extensions that are additional to those of UDS. They include modified error status behaviour, storing persistent DTCs, saving freeze frame data and calculating the In Use Monitor Performance Ratio (IUMPR). In combination with the FIM module, incrementing of the IUMPR counter is deactivated as soon as certain malfunctions are detected. Production-ready OBD extensions of the DEM, DCM and FIM modules for five different automotive OEMs are already available in the AUTOSAR 3 and AUTOSAR 4 basic software from Vector.
37
> Execute performance measurements > Validate new software revisions > Reproduce error states The Solution The system environment consists of four exemplary ECUs, the CANoe test software and the VT System test hardware with various slide-in modules. Four typical ECU classes were defined, and each was represented by an ECU. This produced a meaningful and wellstructured mapping of the later overall system. To represent the system functions, several demo applications were implemented. They are controlled by CANoe via a newly developed CAN-based remote protocol. CANoe uses this protocol to stimulate a function or a special system state and to check the response. All diagnostic requests run as in the real vehicle over a diagnostic tester of the OEM, which is controlled remotely by CANoe. Examples of implemented AUTOSAR functions: > Wakeup & sleep handling > Different transmission modes, update bits, routings > Diagnostic services, security level and DTC handling > J1939 dynamic DLC and BAM
V2.0 | 2013-01
BackgrounD
Dr. Ing. Thomas necker is Team Leader in the Embedded Software Area at Vector in Stuttgart (Germany).
The Customer
> Diagnostic session control and software download > Parameter handling (“Power lost safe”)
OBD Vector.indd 37 6/24
09.01.2014 13:22:30 www.vector.com/contact
6/25
munication between the components runs over AUTOSAR’s
cols of J1939. By that time, however, it was already evident
virtual function bus (VFB), which hides the actual topology
that the AUTOSAR 4.0 support of J1939 wouldn’t be suffi-
of the ECUs. The components define their communication
cient for most J1939 applications.
needs by means of interfaces (Ports), which group data elements or operations. The VFB connects these ports on
Extended J1939 Support in AUTOSAR 4.1
an abstract level. After the application software compo-
AUTOSAR Version 4.1 was released early 2013. The most
nents have been distributed to the ECUs (Figure 2), the
important change related to J1939 was the ability to ac-
RTE takes on the role of the VFB for an individual ECU. This
cess parts of the CAN ID from higher layers. This enables
means that the RTE implements all communication inter-
efficient communication in dynamic networks. When a
faces of the application software components, both be-
message is received, parts of the CAN ID are appended to
tween these components and to the basic software and
the payload data, which makes them available to other
thereby to other ECUs as well.
modules. In the other direction, the sender of a message appends variable parts of the CAN-ID to the payload data
AUTOSAR for Heavy-Duty Vehicles – The Beginnings
to be sent. BSW modules that access the CAN-ID in this
Initially, AUTOSAR was exclusively oriented towards the
way are the J1939 transport protocol, UDS transport pro-
needs of passenger cars, which use a static communication
tocol and UDS diagnostics as well as the PDU router.
matrix. Consequently, AUTOSAR was designed with a
Starting with AUTOSAR 4.1, the J1939 transport layer handles
static model of bus communication. And this static com-
the reception of long messages regardless of the used pro-
munication model initially prevented AUTOSAR from being
tocol variant (BAM/CMDT). To transmit messages, the
used in the heavy-duty vehicle field. The first step to open
J1939 transport layer switches automatically between
AUTOSAR towards J1939 was taken with version 4.0 at the
direct transmission and transmission using one of the two
end of 2009. For this version, Vector Informatik worked
protocol variants based on the actual length of the mes-
together with a European truck producer to specify an
sage and the destination address. Besides, the use of dy-
AUTOSAR basic software module for the transport proto-
namic CAN-IDs reduces configuration effort substantially. Working together with two truck producers, Vector also
AUTOSAR in Heavy-Duty Vehicles
specified three new BSW modules for J1939, which are also
Integration of J1939 in AUTOSAR
shown in Figure 1: >>The “J1939 Request Manager” for the request- response
Now that AUTOSAR has largely become established in the automotive industry, the heavy-duty vehicle industry is show-
protocol according to J1939-21. >>The “J1939 Network Management” for a simple address
ing interest in it. In this industry too, manufacturers want to apply AUTOSAR’s modular concept to save on development
allocation method according toJ1939-81. >>The “J1939 Diagnostic Communication Manager” for
costs. In contrast to the static networking that is used in the automotive industry, heavy-duty vehicles use dynamic communication based on the J1939 standard. This article describes the advantages of integrating J1939 in AUTOSAR as
diagnostics according toJ1939-73.
well as its limitations.
The J1939 Request Manager of AUTOSAR 4.1 handles sendSAE J1939 has become the established standard for network-
The Idea of AUTOSAR – Reuse of Software
ing and receiving of request and acknowledgement mes-
ing and communication throughout the heavy-duty vehicle
Essentially, the development of the AUTOSAR standard
sages. To this end, it offers interfaces to the relevant BSW
industry. J1939 is sometimes used directly and sometimes
was mainly based on two motivations: To standardize the
modules or to application software components via the RTE.
in the form of derived standards. For example, ISOBUS is
hardware and protocol drivers, which would simplify a
In addition, it handles timeout monitoring for sent requests.
used in agriculture and forestry, and NMEA 2000 (National
change of supplier for an ECU; and to modularize the appli-
With the help of the J1939 Network Manager, AUTOSAR 4.1
Marine Electronics Association) is used for maritime appli-
cation software, which makes it easier to handle the grow-
lets users create non-configurable ECUs and ECUs that
cations. In Europe and in certain other regions, only a part
ing complexity of ECUs. The protocol and hardware drivers
of J1939 is used in the heavy-duty truck industry. One as-
are standardized in the form of basic software modules
pect of the heavy-duty vehicle industry that contrasts with
(BSW modules), while the the application software is mod-
the automotive industry is its lower production volumes,
ularized and abstracted in the form of software compo-
which results in higher weighting of software development
nents (SWCs). Figure 1 shows part of the basic software
costs compared to hardware costs and warehousing.
for J1939 applications, as well as the runtime environment
Therefore, it makes sense to focus efforts on the reusability
(RTE) and the application layer.
of software. In practice, however, most developers general-
6/26
ly write new code for each ECU. In a lot of projects, even the
The Software Components Model of AUTOSAR
hardware and protocol drivers are developed repeatedly,
The application software in an AUTOSAR system is subdi-
because there is no common standard to enable the reuse
vided into components that are hierarchically organized in
of drivers and parts of the application software.
compositions. From the application perspective, the com-
Figure 1: Excerpt of the AUTOSAR architecture for heavy-duty vehicles
Figure 2: Distribution of software components from a library to ECUs
6/27
Gaps in the Integration of J1939 in AUTOSAR 4.1 AUTOSAR has made headway in implementing J1939 with Version 4.1, but there are still some gaps – particularly from the perspective of agricultural and forestry machinery. The most obvious omission of AUTOSAR concerns the support of self-configuring and command-configurable ECUs, which can change their addresses at runtime (Figure 3). Furthermore, the following transport protocols from the J1939-based ISO 11783 (ISOBUS) standard are unknown to AUTOSAR: >>FastPacket from NMEA 2000 >>ETP from ISO 11783-6 Implementation of application protocols for universal terminals, farm management and similar components would also be desirable. Moreover, AUTOSAR still does not know how to handle the extended request-response protocol with Request2 messages and Transfer messages, NAME management and other diagnostic messages. Finally, it lacks a solution for simple access to the standardized signals and messages of J1939. Outlook Table 1: J1939 diagnostic messages supported in AUTOSAR 4.1
Currently, AUTOSAR is not working on closing the described gaps. It appears, however, that increasing numbers of commercial vehicle manufacturers are becoming involved with AUTOSAR, especially in the agricultural and forest man-
can be configured by software update. If the address allo-
agement industries. As a result, it is anticipated that the
cation for the desired address fails, the ECU goes offline
ISOBUS extensions will also be standardized in AUTOSAR
after sending the “CannotClaimAddress” message.
over the long term.
The J1939 Diagnostic Communication Manager of AUTOSAR
Until then, tool and basic software manufacturers will come
4.1 already supports many J1939 diagnostic messages
up with interim solutions. For example, Vector Informatik is
(Table 1). Not yet supported are OBD messages and mes-
currently developing support for fully dynamic address allo-
sages for memory access, calibration and flashing. A great
cation and for convenient linking the application to the
advantage of J1939 diagnostics in AUTOSAR 4.1 is the
J1939 catalog of messages and signals. An implementation
shared access with UDS diagnostics to the fault informa-
of the ETP and FastPacket transport protocols is also al-
tion stored in the AUTOSAR “Diagnostic Event Manager”.
ready planned.
This assures uniform management of the diagnostic information for both diagnostic protocols.
Translation of a German publication in Hanser automotive, November 2013 Image rights: Vector Informatik GmbH Links: Vector: www.vector.com MICROSAR basic software: www.vector.com/microsar
Figure 3: Dynamic address allocation in ISOBUS: ECU A changes its address, because the just connected ECU C occupies address 10
6/28
Dipl. Inf. Martin Schlodder studied computer science at the University of Tübingen, and is working at Vector Informatik since 2004. He develops J1939-software and is a member in AUTOSAR working groups for the integration of J1939. E-Mail:
[email protected]
addition, this step lets ECU suppliers use a uniform software platform for multiple automotive OEM customers. Nonetheless, from the beginning AUTOSAR focused primarily on the overall development process. Therefore, the interfaces between participating partners were standardized and a methodology model was defined. The full benefits of AUTOSAR can only be achieved when all of its elements are implemented systematically. New Division of Labor While automotive OEMs previously created a text-based specification for each ECU and subcontracted its implementation to a supplier, AUTOSAR makes it possible to deFigure 1: Hype cycle according to Gartner Inc.
rive and share precise machine-readable specification requirements that come from a design of the total “vehicle electronics” system. Different suppliers can implement these requirements with assured processes and high effi-
AUTOSAR – Equipped for Everything? Over the past ten years, AUTOSAR has decisively shaped and advanced the world of automotive electronics. Today, AUTOSAR is the foundation for efficiently implementing distributed functions and integrating software components from different sources. But the desired productivity gains are only realized if the entire development process is based on the new standard.
In the early era of microcomputer-based automotive elec-
this required additional coordination effort and very exten-
tronics, a separate ECU was developed for each functional
sive integration tests. Problems also occurred when an al-
unit such as engine management or transmission control.
ternate supplier or new supplier was added for an ECU (e.g.
Coordination with the other ECUs was implemented via
for a new vehicle generation). This incurred additional coor-
control lines, e.g. lines carrying pulse-width modulated sig-
dination and testing effort.
nals. Growing functionality, however, was driving the num-
To improve this situation, automotive OEMs and suppliers
ber of control lines and their costs upwards. That is why, in
founded the AUTOSAR consortium (AUTomotive Open
1983, Bosch began to develop a network protocol – the
System ARchitecture) in 2003. Its standardization would
Controller Area Network, or CAN – which was implemented
make it possible to integrate algorithms, in unmodified
in a production vehicle for the first time in 1990. It enabled
form, into the ECUs of different manufacturers, and this
the exchange of large amounts of data between ECUs in
would support the distribution of functions to multiple
real time. This, in turn, unleashed the creativity of develop-
ECUs much better.
showing excited interest and will hop aboard the train
ciency. This enables a division of labor that does not require
sooner or later. As soon as it appeared, enthusiasm was very
increased effort at the interfaces between the partners on
high, and this led to some inflated expectations (Figure 1). Over time, the desire for a simple and cost-effective solu-
the following levels: >>ECU hardware
tion had to be tempered due to the growing volume of
>>Basic software
specifications (Figure 2).
>>Application software
AUTOSAR is often understood primarily as the basic soft-
>>Integration and comprehensive testing.
ware. Undoubtedly, this basic software is an important component. It contains an operating system, communica-
This division of labor has many advantages. Specialized com-
tion and management services, and it offers a uniform in-
panies can be contracted for specific sub-areas, and this leads
terface (Runtime Environment) for the actual application.
to better solutions that are also more cost-effective. They
Often automotive OEMs and suppliers begin their migra-
range from ECU hardware suppliers to suppliers of basic
tion to AUTOSAR with the basic software – a reasonable
software components, developers of individual driver assis-
step, because the specification of the basic software is well
tance systems and suppliers of just certain parts of a com-
validated, and many producers offer implementations. In
plex assistance system. The automotive OEM can under-
ment engineers in implementing many new convenience
6/30
functions such as “Keyless Go” and enabled significant im-
More than Basic Software
provements in the areas of safety, fuel economy and ex-
Ten years later, AUTOSAR is still a hot topic, and with good
haust emissions.
reason. Over 100 companies have developed specifications
However, the approach was still “one ECU for each func-
in a number of working groups. Meanwhile, the fourth main
tion” – and each ECU was developed and produced by one
version has been published. Vehicles with AUTOSAR are in
supplier company. Whenever multiple ECUs from different
production, many automotive OEMs are currently develop-
manufacturers were involved in implementing a function,
ing vehicles with AUTOSAR, and nearly all of the others are
Figure 2: Even AUTOSAR is not all that simple: growing content of the specification
6/31
AUTOSAR – Equipped for Everything?
Not an End in itself AUTOSAR is a consistent continuation and standardization of a development methodology that has evolved in autoFigure 3: Universal process: software development with AUTOSAR
motive electronics over several decades. AUTOSAR relies on established and proven methods, and it utilizes the latest software technologies to enable the development of a new generation of vehicle functions. The progression towards more automated driving sets new requirements with
take tasks relevant to its competitive advantage to achieve
Tools
regard to complexity and safety. Nonetheless, standardiza-
complex innovations. This avoids having competitors quick-
Development tools had to be created in parallel to develop-
tion must not be an end in itself. It is important to precisely
ly benefit from the development via suppliers who would
ment of the AUTOSAR specification itself. As a result, the
observe the extent to which its advantages outweigh po-
otherwise be responsible for creating the innovative content.
first tools were not always very mature. The higher the level
tential disadvantages and whether disruptive technologies
In addition, clear structuring of the total system makes it
of performance that was required of the tools, the greater
might force out established players. There are signs of this
possible to re-use individual components to a great extent.
their development effort, and the later their availability
already; just consider some new e-vehicle manufacturer or
The introduction of this new methodology requires a re-
and maturity. Since increasing stability has been achieved
the autonomously driving car from Google.
alignment of the methodologies of all participants in the
in AUTOSAR specifications in recent years, and it has
supplier chain. Consistent frontloading is necessary with
benefited from experience from many production projects,
Translation of a German publication in Mobility 2.0,
AUTOSAR. The relevant (sub-) contractor must formulate
very high-performance tools are now available for pro
March/2014
its specifications much more precisely and formally. Com-
ductive use. “PREEvision” might be cited as an example
pared to today’s methodology, this requires considerable
here. PREEvision is a development platform for the entire
Image rights:
rethinking and a shift of responsibilities and tasks. This, in
E/E-product development process according to AUTOSAR
Vector Informatik GmbH
turn, results in an industry-wide change process, which will
(Figure 3). It integrates the design, evaluation, optimiza-
be painful for many participants. Currently, the industry is
tion and documentation of E/E architectures in one tool. It
Links:
in the midst of a changeover. In the transition time, much
exports and imports the interfaces definition in AUTOSAR
Webpage Vector: www.vector.com
more coordination effort is often required in the supplier
format. To achieve comprehensive support of E/E develop-
Product Information PREEvision:
chain with its significantly larger number of participants.
ment areas, other components are necessary; they range
www.vector.com/preevision
This harbors risks. A chain is only a strong as its weakest
from requirements analysis to the provision of a collabora-
link. Short-term change wishes and quickly performed error
tion platform and finally the management of variants
analyses can become a Herculean task with so many par-
(Figure 4).
ticipants. In some places, projects in this phase give the im-
Each standard, including AUTOSAR, harbors the risk that it
pression that AUTOSAR does not deliver what it promises,
could put the brakes on innovations. The current example
and that it leads to additional costs. As in any change pro-
of “Ethernet in the vehicle“ shows that this can be avoided
cess (Figure 1), it is necessary to cross the “trough of disillu-
by pragmatic approaches. The standard is being developed
sionment”. Therefore, the goal must be to complete chang-
in parallel with first implementations. This promotes quick
es “on the fly” as quickly and systematically as possible.
definition of a practice-based standard, which enables
Those vehicle developments that were developed with
quick market introduction. The down side is that first im-
AUTOSAR methodology – based on the maturity levels of
plementations are based on a temporary level of the stan-
the participants – clearly demonstrate that this effort is
dard, so they will need to be modified later with additional
worthwhile. The objective must be to reach the “plateau of
effort.
Dr. Helmut Schelling is a founder and managing director of Vector Informatik GmbH.
productivity” as quickly as possible. A powerful tool chain can make a decisive contribution here.
Figure 4: One tool for verything: contents of the e “PREEvision” platform
6/32
6/33
today as well as all future parameters. However, no one
defined configuration of arbitration rules, logical expres-
would want to configure the thousands of necessary pa-
sions and actions, for reacting to mode changes in other
rameters in such an editor without further support.
BSW modules or for requesting mode changes itself. An assistance function now helps to configure the BswM such
Specific Editors and Assistance Functions
that it behaves similarly to the relatively easy to handle
There are a number of approaches for developing a soft-
ECU State Manager (EcuM) from AUTOSAR 3.
ware tool that can simplify this work. A specially developed
User-friendly Configuration of AUTOSAR ECUs with Specialized Software Tools The simple CAN ECU is a thing of the past. Now, a typical ECU utilizes many functions of the AUTOSAR basic software to perform its complex tasks. However, the more functions there are, the more difficult and extensive the configuration process is too. Without tool support, developers would be lost.
editor displays the relationships between parameters and
Deriving Parameters from the System Description
simplifies the configuration process, e.g. by bulk operations.
Configuration of the communication modules for CAN, LIN,
In addition, such an editor can group parameters themati-
FlexRay or Ethernet must match the system description
cally – even extending beyond module boundaries. The edi-
that originates from the OEM. AUTOSAR provides for der-
tor’s graphic views make it easier to understand the com-
ivation of a basic configuration of the modules (the Base
plex configuration. Such tools are helpful and necessary in
EcuC) from an ECU-specific extract of the system descrip-
all domains of the basic software such as communication,
tion (System Extract). In practice, however, the situation is
mode management, diagnostics, memory management
somewhat more complicated (Figure 3): AUTOSAR has de-
and I/O. When using an editor in the area of memory do-
fined a standard format for the system descriptions. But in
mains, for example, the developer can rather simply insert
addition to this format, OEMs also use the traditional DBC,
a memory block, which is then consistently configured in
LDF and FIBEX formats. Furthermore, the TIER1 supplier
the non-volatile RAM manager (NvM) as well as in the flash
might use its own system descriptions, e.g. for private CAN
EEPROM emulation (Fee). It is also very easy to estimate
buses within the ECU or for LIN buses that connect sensors
the overhead from the ratio of user data to block size in a
with the ECU. The software tool must therefore identify all
graphic display (Figure 2).
possible types of input data, convert traditional formats by
Assistance functions are also helpful in the configuration
suitable preprocessing methods and generate ECU-specific
process. When the developer changes a parameter, for ex-
extracts. It must also be possible to merge multiple, sepa-
ample, other parameters that depend on it are automati-
rate system descriptions into a common description. Only
cally corrected by a rules system. For more complex tasks,
then is it possible to generate the Base EcuC.
such as mapping runnable entities to operating system
Similar considerations apply to the diagnostic modules. The
tasks, assistants may be of help: The developer can per-
configuration of the modules must match the ODX specifi-
form tasks like selecting runnable entities of the SWCs
cation of the ECU. Therefore, the ODX file must also be in-
based on similar trigger conditions, assign a task and final-
cluded into the Base EcuC.
ly define the execution sequence within the task.
Sometimes the TIER1 also has a standard configuration for
Another example from the mode management domain:
its projects that is available directly in EcuC format. These
The BswM module in AUTOSAR 4 permits completely user-
configuration elements should also be contained in the Base EcuC. The BSWMD files that the tool needs in order
Three factors affect the complexity of ECU configuration: >>More standardization A large share of ECU software has now been standard-
controller Abstraction Layer modules (TIER2-MCAL).
to check the configuration can originate from various
This means that more coordination effort is required
sources. They are either provided by the TIER2-BSW supplier,
initially in the configuration process.
ized as basic software by means of AUTOSAR. However, the AUTOSAR principle “configuration instead of imple-
How do Software Tools Help here?
mentation” forces developers to create a consistent
The AUTOSAR standard continues to develop in a highly dy-
overall configuration from the start. There are no
namic manner. There are changes with each new release: the
rovisions for making corrections directly in the code. p >>More functions
modules are defined. All of these modules come with their
New microcontrollers with multiple cores and memory
own configuration parameters. However, the AUTOSAR
protection features and new networks such as Ethernet
configuration approach is fundamentally able to handle
have increased the scope of the basic software, and
this dynamism with its formally described module struc-
therefore configuration needs. >>New cooperation models
6/34
functionality of existing BSW modules is changed and new
tures and parameters. This makes it possible to quickly and easily define the Basic Software Module Descriptions
The AUTOSAR methodology encourages new roles in the
(BSWMD) contained in the delivered BSW. At first, this for-
development process (Figure 1). In addition to the
mal method sounds enticing as an approach for tools: the
supplier of the AUTOSAR basic software (TIER2-BSW),
tool company would develop a generic tool with a reason-
there are also suppliers of the application software
able amount of effort, and then all parameters could be
components (TIER2-SWC) and hardware-related Micro-
individually configured – those parameters that are known
Figure 1: Roles in an AUTOSAR development project
Figure 2: Advanced views simplify the ECU configuring
6/35
User-friendly Configuration of AUTOSAR ECUs with Specialized Software Tools
or they might be supplied by the microcontroller manufac-
scription and the delivery date of the ECU is very short. A
turer so that they match the MCAL modules.
tool must therefore be able to update the configuration
Finally, the SWCs might be contained in the system extract
with the new input data as automatically as possible. A
which the OEM provides to its suppliers. According to the
project update function can do this by generating a new
AUTOSAR 4 method, the system extract is first used to
Base EcuC, and by updating the actual configuration to the
generate an ECU extract, which represents a flat perspec-
new Base EcuC.
tive of the SWCs.
But what happens when there are errors in the system de-
Afterwards, for example, the ECU extract is extended to
scription? Even when the problems have been clarified with
include other SWCs which might be provided by external
the OEM, a corrected system description is usually not
suppliers (TIER2-SWC).
available immediately. In such cases, the ECU developer
Using the ECU Extracts and the Base EcuC, the ECU devel-
might want to intentionally ignore some of the derived pa-
oper creates the overall configuration of the BSW and RTE
rameters and overwrite them with other values. This is a
(Runtime Environment). Here, the tool should treat those
way to correct the error directly in the ECU configuration.
parameters taken from the Base EcuC as write-protected
Since such a deviation is always critical, the ECU developer
to avoid deviations from the system extract.
should be able to explicitly set the parameter status as
“Merge” Function for Multiple Developers Working in
“user-defined” in the tool. As long as the parameter is in
Parallel
Project Update
this status, the tool may not overwrite its value when per-
Even on smaller ECU projects, multiple developers are al-
Over the life of the project, the developer continually re-
forming a project update. Only when the ECU developer
ways working on the project simultaneously. If competen-
ceives updated input data. Typically, these updates arrive
removes the status “user-defined”, the parameter adopts
cies are clearly defined (e.g. “Colleague xy is always respon-
at different points in time and with varying frequency. The
the derived value.
sible for the operating system.”), then it is possible to avoid
would be of help here (Figure 5). Ideally, the user could view
OEM distributes new system descriptions according to the
The tool also helps in coordination between the ECU devel-
making parallel changes to the same module or to the
the differences directly in the same editors with which the
specific milestones of vehicle development, while the diag-
oper and the OEM, e.g. by generating a report on overwrit-
same SWC. Typically, however, the developers are working
user created the configuration. Then the user would feel “at
nostic description is typically updated much more frequent-
ten parameters.
in parallel, and they develop ECU functions that run verti-
home” and would not have to work with a separate tool
cally through all of the architecture layers of the ECU soft-
with different, unfamiliar view of the data.
ware (Figure 4). In the times of manual C-coding, the inte-
Nonetheless, the following rule of thumb applies: The fewer
grator would then merge the different code branches on
the changes that need to be merged the better. Massive
textual level. With AUTOSAR, however, this would mean
changes to the configuration might result from a project
that the integrator would have to merge XML files in
update to a new communications matrix (C-matrix), for
ly. Often, the time span between receiving the system de-
Figure 3: Workflow for creating and updating an ECU configuration based on the example of DaVinci Configurator Pro from Vector
6/36
Figure 4: Development of “vertical” ECU functions
Figure 5: Diff/Merge support in DaVinci Configurator Pro
AUTOSAR format that could be many megabytes in size. It
example. Therefore, the following practical procedure is
would be practically impossible to compare or merge an
recommended: Starting from an integration milestone
AUTOSAR configuration using general XML tools. The
MS0, the feature developers each do their development
structure of the file and the many references within the file
work on a separate branch (Figure 6). The branches are
are much too complicated for that.
merged, one after another, in the main branch – possibly in
Only an AUTOSAR- tool that clearly displays the differences
several intermediate steps (MS1 to MS3). Only then can the
in the AUTOSAR configuration and offers merge options
integrator update a project to a new C-Matrix (MS4).
Figure 6: Working on the same ECU configuration in parallel
6/37
Afterwards, new branches can be added and functions developed that match the new C-Matrix. All of this can be supported by a Configuration Management (CM) system, which also manages the implementation files of the SWCs. Available Tools The tool DaVinci Configurator Pro from Vector already enables the described working method. Soon, DaVinci Configurator Pro will also permit the creation of configuration variants, which can be dynamically switched in the ECU. They are also known as Post-Build Selectable Variants. Here too it is important to intelligently implement the available AUTOSAR concepts in tool functions. Then the developer gets further valuable support in the development of AUTOSAR projects. Translation of a German publication in Elektronik automotive, Issue 4 / 2014 Image rights: Vector Informatik GmbH Links: Vector AUTOSAR Solution: www.vector.com/autosar Matthias Wernicke (Dipl.-Ing. (FH)) After completing his studies in Industrial Electronics at the University of Applied Science at Ulm, he was employed at the Daimler Research Institute in Ulm for four years. Since early 2000, he has been employed at Vector Informatik in Stuttgart working on the development of methods and tools for designing distributed electronic functions in motor vehicles. Today, he is responsible for product management of the DaVinci AUTOSAR tools.
AUTOSAR ECUs Your Key to Successful Development From Requirements to Production
One step ahead with the Vector solution for AUTOSAR. > Basic software tuned specifically to your project,
> Reduced development and certification effort for
available for a wide variety of microcontrollers > Efficient development work in all phases with
ECUs in accordance with ISO 26262 up to ASIL D > Test comprehensively: from release of the first
an intelligent tool chain > Powerful security functions to protect the ECU
software module to integration testing > Reach your goals faster with professional and
from unauthorized access
tailored AUTOSAR services
Take advantage of the benefits of practice-proven products and Vector’s experience in developing your production-ready ECUs. Information and downloads: www.autosar-solutions.com
6/38
Vector Informatik GmbH | Germany · Austria · Brazil · China · France · India · Italy · Japan · Korea · Sweden · UK · USA | www.vector.com
Figure 1: The developer groups the tasks together in OS applications and distributes them to the cores.
a multi-core architecture intended to increase computing
decomposition: The task is to ensure freedom from inter-
power.
ference between the OS applications. This essentially requires runtime monitoring and the avoidance of erroneous
Multi-core Architecture with Distributed Software
changes to memory content of relevance to safety.
Multi-core architecture can be used to increase computing
AUTOSAR goes Multi-core – the Safe Way Two major topics are currently at the center of software development activities for automotive ECUs: First, the trend in computer architecture towards multicore processors and second the safety standards demanded by ISO 26262. Each of these topics is already complex enough in its own right, so what will be the consequences of the two together?
power or – in the case of safety-related systems – for the
Runtime Monitoring
implementation of diversity algorithms such as ASIL de-
In scalability class 2, AUTOSAR features runtime monitor-
compositions. The developer assigns the software modules
ing. This is however not sufficient for safety-related appli-
to the OS applications defined in AUTOSAR on the basis of
cations. The AUTOSAR operating system checks that no
parallelizability and in accordance with the safety concept.
task requires an excessive runtime or blocks interrupts for
This corresponds to partitioning as defined in ISO 26262
too long. However, configuration of the correct, safe task
and refers to areas within an ECU which have to be able to
sequence and task triggering presents developers with a
run without causing any mutual interference (freedom
high degree of complexity which is difficult to secure. An
from interference). In multi-core ECUs the OS applications
alternative solution is available from TTTech and Vector
ment process in automotive engineering. The requirements
are assigned to the various processor-cores (Figure 1).
Informatik. This takes the form of a program flow monitor
to increase the computing power without having to have a
for the functions of an ECU are assessed with respect to
From the point of view of the developer it is irrelevant
developed in accordance with ASIL-D which monitors the
higher clock speed. This is however only possible if enough
their relevance to safety on the basis of a hazard and risk
whether the purpose of partitioning is parallelizability or
execution times and sequence of the tasks and the func-
of the application software can be parallelized. The classic
analysis and the appropriate ASIL (Automotive Safety
reference in this context is Amdahl’s law. Taking a dual core
Integrity Level) is assigned. What are the consequences for
processor and software with a parallelizability of 50 % as
a multi-core software architecture if safety-related func-
The main reason for introducing multi-core architectures is
an example, this yields a maximum increase in power of
tions have to be implemented? Before answering this
only 30 % as compared to a single-core architecture.
question there are a few points to note with regard to the
To achieve the best possible computing power, developers have
lockstep concept for multi-core processors used in many
to make every effort to minimize inter-core resource shar-
safety projects.
ing when distributing the software modules. The resources concerned are hardware registers and – in most cases – data
Lockstep Mode
areas. The challenge presented by cross-core resource utili-
In lockstep mode two cores execute the same code. An in-
zation is not so much access coordination but rather the
dependent comparator compares the results and gener-
avoidance of wait-states in the case of concurrent access to
ates a trap in the case of a discrepancy. The next step de-
the shared resources. In such situations there is a loss of inde-
pends on the hardware and the safety concept of the ECU.
pendent data processing and parallelization is not as useful.
The design of the hardware must ensure that it assumes a safe state following the occurrence of the trap. Apart from
6/40
Functional Safety as per ISO 26262
error handling, no multi-core software extensions are re-
Implementation of the functional safety requirements stip-
quired as both cores execute the same code. In other words:
ulated by ISO 26262 is now an integral part of the develop-
Even though use is being made of several cores, this is not
Figure 2: Together with the check points in the application, flow monitoring ensures the correct sequence.
6/41
AUTOSAR goes Multi-core – the Safe Way
In the AUTOSAR architecture model this data exchange be-
cores (Figure 1). With the DaVinci Configurator Pro config-
monitor is created for each core. The monitor receives in-
tween two tasks takes place by way of the Virtual Function
uration tool from Vector Informatik this can be done with
formation on function execution through the check points
Bus (VFB). The VFB is implemented by the Runtime Envi-
just a few clicks. The integrated RTE generator automati-
incorporated into the software (Figure 2). These check
ronment (RTE).
cally takes care of configuring the correct communication
points are only passed through in the correct order and
The RTE has to satisfy the following additional demands
methods (intra-core or inter-core) between the software
with the correct timing if the safety-related parts of the
for a safety-related ECU with multi-core architecture: It
modules.
program are correctly processed.
has to permit communication across memory partitions
In other words, a lot of support is already available for
The central watchdog manager gathers the status mes-
and at the same time be able to distinguish whether a
multi-core ECUs in the form of basic software and config-
sages of all monitors and triggers the watchdog. It is not
communication path runs across core boundaries (inter-
uration tools for example. It is far more difficult to realize
possible to manage each core separately, as the tasks are
core) or between two tasks running on the same core
good tool support for creation of the software architecture
often interdependent across core boundaries. In addition,
(intra- core). Inter-core data transfer requires additional
and distribution of the software components to the pro-
the AUTOSAR specification only permits the joint re-start-
coordination mechanisms. For this purpose, the operating
cessor cores. In fact it is usually restricted to the evaluation
ing of all cores. The watchdog manager therefore has to be
system provides the RTE with a function known as IOC
of variants. In the foreseeable future, ECU developers will
developed as a central module for the entire ECU. In con-
(Inter-OS-Application Communicator). This allows the ex-
still be called upon for their expertise and experience.
trast, the actual monitors run independently on each core
change of data between tasks and interrupt service rou-
and are capable of informing the watchdog manager of
tines on various cores.
tions contained in these. An instance of this program flow
Translation of a German publication in Elektronik automotive, June/2014
their status across core boundaries. Use of Standard Solutions Memory Protection and Safe Communication in the ECU
Ensuring functional safety as defined by ISO 26262 on
Image rights:
Perfect freedom from interference is only possible if the
multi-core ECUs would therefore appear to be no easy
Vector Informatik GmbH
hardware provides a Memory Protection Unit (MPU). This
task. It does not how-ever involve re-inventing the wheel
ensures that the application parts can only access pre-de-
but simply using it correctly. Vector Informatik and TTTech
Links:
fined memory areas (Figure 3). These memory areas are
can provide ECU developers with operating systems, RTE
Website Vector: www.vector.com
defined separately for each core but have to share the
and program flow monitoring for multi-core architectures
hardware resources (RAM, etc.) with the other cores. The
up to ASIL-D.
operating system plays a central role: On each task change
Generally speaking, multi-core systems are far more com-
it has to re-program the MPU to effect a change of memo-
plex than single-core concepts. This need not however ap-
ry partition. This part of the operating system, which is
ply to configuration of the basic software: Once the soft-
responsible for context change, is a safety-related compo-
ware has been distributed to the processor cores, the re-
nent and must always conform to the highest required
maining configuration work for a multi-core system is no
safety level.
more difficult than for a single-core architecture with the
Protection against the erroneous overwriting of data is one
aid of optimum tool support. The developer groups tasks,
aspect. The other is the need for the correct exchange of
interrupt service routines, etc. together in containers, the
data between the tasks and across various processor cores.
OS applications and then assigns these to the processor
Dr.-Ing. Helmut Brock has been with Vector Informatik since 1999 where he works as Operating Systems Product Manager.
[email protected]
Dipl.-Ing. (FH) Joachim Kalmbach has been with Vector Informatik since 2006 where he works as Product Manager in the Embedded Software sector. His main fields are AUTOSAR and Multi-core.
[email protected]
Figure 3: The memory protection unit ensures that the application parts can only access pre-defined memory areas.
6/42
6/43
Figure 1: AUTOSAR structure
AUTOSAR-compliant Development of an In-car Radio Product Using MICROSAR for the European Market Alpine Electronics, Inc. (“Alpine”), manufacturer of car audio and navigation systems, developed an AUTOSAR-compliant in-car radio product for a European automotive manufacturer for series production in 2013. Alpine completed development of AUTOSAR related software components for CAN, diagnostics and other functions within one year starting from October 2010 and then also completed development of other software components. By using MICROSAR from Vector Japan Co., Ltd. (“Vector”) as the AUTOSAR platform and developing a proprietary wrapper that leveraged existing software assets, Alpine succeeded in its product development while meeting a tight schedule and high quality demands.
AUTOSAR Enables Sharing of Automotive Embedded
tomotive embedded software as assets. AUTOSAR is a sys-
Software as Assets
tem that abstracts the differences in hardware, such as
Electronics becomes more widely used in automotive sys-
microcontrollers, and enables a standardization and reuti-
tems, such as power-train, safety functions, and infotain-
lization of in-car application software assets, in short.
scribed the challenges. “We were asked to build an in-car
on combination of in-house solutions, Alpine contracted
radio for a European automobile manufacturer, and they
MICROSAR BSW modules. Alpine used MICROSAR SYS for
specified as part of the RFQ that it must be developed in
its error reporting, communication management, and ECU
compliance with AUTOSAR Release 3.0. We had never
state management, MICROSAR MEM for managing flash
developed any product using AUTOSAR, so it was our first
memory, and MICROSAR CAN and MICROSAR COM for its
time.” Also this particular in-car radio uses a Renesas SH2A
CAN control. They did not use any AUTOSAR runtime envi-
microcontroller, with existing software assets based on
ronment (RTE), because a large number of changes were
µITRON (see Figure 2). Alpine immediately began work on
expected in reuse of the existing software assets. Also, be-
introducing AUTOSAR. For the development infrastructure,
cause the conventional µITRON-based operating system
the company selected MICROSAR, the AUTOSAR-based
would be utilized, MICROSAR OS was not used. The entire
embedded software products developed by Vector. Kusano
configuration is shown in Figure 3. MCAL (Microcontroller Ab-
explained. “We selected MICROSAR because Vector is one
straction Layer), which abstracts the microcontroller hard-
of the suppliers recommended by the European automobile
ware, was not supplied from the microcontroller vendor at
manufacturer and because we had worked with Vector in
the start of development, so it was developed at Alpine.
the past on CAN bus-related development.”
As mentioned above, Vector’s MICROSAR was chosen as
Next, Alpine consulted with Vector and gained an understand-
the BSW modules. The Complex Drivers, which is highly de-
ing of the functions realized by the basic software (BSW)
pending on the vehicle variants, was provided by the auto-
of AUTOSAR. After analysis to extract minimum set of
mobile manufacturer. The software components (SW-C),
BSW regarding with required functionalities and possibility
which are equivalent to the application layer, were developed by Alpine using existing assets based on µITRON.
ment. The transition from conventional mechanical and
6/44
hydraulic systems to E/E architecture will never stop ad-
MICROSAR Selected at the Recommendation
vancing in the future. While evolving electronics enrich the
of European Automobile Manufacturer
automotive functions, the number of man-hours required to
AUTOSAR brings certain advantages on high efficiency on
develop the control software are higher than ever before,
automotive software development. However, for manufac-
creating a significant burden on automobile manufacturers
turers and suppliers using it for the first time, it’s not really
and suppliers. To deal with this situation, the open and
easy to read through all the specifications and understand
standardized automotive software architecture AUTOSAR
the full picture. It is also challenging to understand the
(AUTomotive Open System ARchitecture) (see Figure 1)
detailed development activities.
was jointly developed by automobile manufacturers, sup-
Alpine was among one of those car audio and navigation
pliers, electronics manufacturers, semiconductor vendors,
system companies struggling to go with AUTOSAR. Tomohiro
and software vendors, to aim enhancement of reuse of au-
Kusano (Alpine’s OEM Product Development Dept.) de-
Figure 2: In-car radio for European automobile manufacturer developed based on AUTOSAR
Figure 3: Software stack of developed in-car radio
6/45
AUTOSAR-compliant Development of an In-car Radio Product Using MICROSAR for the European Market
Leveraging Existing Assets with a Proprietary Wrapper
development work was nearly complete, and next, the
without Using RTE
weight shifted to development of the SW-C, which is the
During actual development, the schedule became an initial
application layer. The SW-C, which is comprised of func-
issue. Kusano recalled the process. “We began develop-
tions including the radio tuner and USB audio playback,
ment in October of 2010, but we had to provide the client
follows the conventional architecture that interfaces with
with a prototype based on the evaluation board by Febru-
µITRON using the communication server named Virtual
ary 2011, so we had to have big progress with AUTOSAR on
MOST and interfaces with the BSW modules using a spe-
a very tight schedule.”
cially developed wrapper without using the RTE (see Figure 5).
As a solution, training on the development flow of AUTOSAR,
Kusano explained. “The number of man-hours required to
a BSW functional overview, and configuration of the
develop the wrapper was about five man-months, but that
MICROSAR environment and BSW were held at Alpine by
figure is smaller than it would have been if using the SW-C
instructors from Vector to improve the skills of the develop-
with an RTE.” After performing a series of tests, the team
ment leads. At the same time, development of MCAL was
completed a bug-free version of the prototypes incorporat-
immediately started. Next, Alpine worked with Vector to
ing all functions in October 2011, and series production was
implement an integration of products, starting with the
started at the end of 2013.
MICROSAR BSW modules, Alpine-developed MCAL, and
Figure 5: Development of a proprietary wrapper to replace the RTE and reduce the changes to software assets
Complex Driver and CAN database (*.dbc) files that the cli-
Launching Product Development with AUTOSAR
ent provided, and also combining EcuC (ECU configuration
Release 4.0
description), GENy and DaVinci Configurator Pro (both
Although increased man-hours is a typical concern with
Vector’s configuration tools1) (see Figure 4).
AUTOSAR-based development, Kusano revealed that there
“The schedule leading up to the provision of the prototype
was no significant increase, with only two people (it be-
to Vector Japan were handled within 24 hours, and we were
provide products and services that best meet the needs of
was tight, and in the end, we went to Europe, where the
came one at the final development stage) required for con-
very pleased with their technical support.”
our customers.”
automobile manufacturer is located, and worked together
figuring the MICROSAR BSW while each did other develop-
Alpine has already started developing new products using
with Vector to accelerating integration and perform test-
ment tasks in parallel, only three people (only in the initial
AUTOSAR Release 4.0, with series production scheduled for
Image rights:
ing,” explained Kusano.
development phase) required for integration work while
2016. “Introducing MICROSAR RTE that we skipped this
Cover and Figure 1: Vector Japan
These efforts were worthwhile, as the team successfully
they also did other tasks too, and only about five man-
time will be next challenge in our next product. We will work
Figure 2-5: Alpine Electronics, Inc.
provided the prototype based on the evaluation board by
months required for wrapper development.
to develop new products with the continuous cooperation
February 2011, as requested by the client. They were also
Kusano also revealed that he was quite satisfied with the
of Vector,” Kusano said.
Contact in Japan for further information:
able to release a prototype which is based on the hardware
quality of MICROSAR provided by Vector. “During the eval-
Now, as AUTOSAR has been getting more mandated in
Sales Division (Embedded Software), Vector Japan Co., Ltd.
for series production by April 2011. The AUTOSAR-related
uation process, we discovered several problems, but they
RFQs of European automobile manufacturers, Alpine’s
[Tokyo] Tel: +81 3-5769-7808
were mainly caused by incorrect settings, wrong use or
example of development with AUTOSAR by introducing
E-mail:
[email protected]
problems caused by other tools. There was only one prob-
MICROSAR for short turnaround and reduced man-hours
lem within MICROSAR itself. Moreover, all detailed inquiries
will surely serve as an exemplary model for other suppliers
1 In new AUTOSAR 4.x projects GENy is no longer used for configuring AUTOSAR BSW. The current solution uses just one tool – DaVinci Configurator Pro.
Find your local contact person: www.vector.com/contact
Reviewing the Project Tomohiro Kusano OEM Product Development Dept. ALPINE ELECTRONICS, INC. “Thanks to the high-quality MICROSAR product and Vector’s support, we were able to meet the tight schedule and quality demands of our European automobile manufacturer client. AUTOSAR-compliant development will certainly become more important in the future, and we would like to leverage our experience and knowledge to other parts of the company and to new products.” Tsuyoshi Sakurai Embedded Software Dept. (PES) Vector Japan Co., Ltd. Figure 4: Flow of Integration Using MICROSAR
6/46
“The expertise of the Alpine engineers also helped us out. We were very happy that our AUTOSAR solution could efficiently contribute to their development. We will continue to
6/47
and watchdog initialisation and state-handling, a non-vol-
The AUTOSAR Operating System
atile memory software stack for various memory devices,
In particular, the AUTOSAR OS offers many more features
an abstraction driver layer for the microcontroller peripher-
that were currently unavailable or not even considered by
als and also the operating system (OS).
the ECU supplier. In the past, a simple single-tick or super- loop scheduler may have been adequate to host all the ECU
Increased Processing Demand from the AUTOSAR
application tasks. Now, with the alternative inclusion of an
“Sweet Shop”
AUTOSAR OS, a new set of operating system features be-
The AUTOSAR standards are still growing and evolving to
comes immediately available to the software engineers.
meet the very latest vehicle E&E requirements – at the end
The AUTOSAR OS is offered in a range of “Scalability
of 2014 the AUTOSAR Basic Software attained its highest
lasses”, extending from SC1 to SC4: C >>AUTOSAR OS Scalability Class 1 extends the OSEK/VDX
ever level of complexity so far, when version 4.2 was released. Over 90 scalable embedded software modules are defined and are supplied along with powerful configuration tools and code generators in conjunction with a set of further standards for the workflows, methodologies and data exchange formats.
standard operating with the addition of schedule tables >>OS Scalability Class 2 extends AUTOSAR OS SC1 with the addition of timing protection >>OS Scalability Class 3 extends AUTOSAR OS SC1 with
When an ECU supplier chooses to equip their ECU with
the addition of memory protection >>OS Scalability Class 4 extends AUTOSAR OS SC1 with
AUTOSAR Basic Software, they find themselves being of-
the addition of both timing and memory protection
fered a new range of feature-rich embedded software modules that become available as off-the-shelf commodi-
The additional features within the AUTOSAR OS do not
ties. Lengthy software development lead-times are no lon-
come without a resource penalty and, like every other mod-
ger a constraint in deciding whether to build further fea-
ule within the AUTOSAR Basic Software, the increased
tures into the ECU, since including an additional AUTOSAR
functionality requires RAM and ROM resources within the
module simply becomes a tick-box within the Basic Soft-
microcontroller and consumes additional processor run-
ware configuration. Software architects can find them-
time overhead. These additional requirements would gen-
selves like “kids in a sweet shop” with over 90 software
erally need to be supported with higher ECU processing
modules to pick and choose from.
power and greater microcontroller memory capacity.
Of course, each of these software modules comes at its
A common misconception has subsequently arisen, that
within an AUTOSAR System
own cost; not only in terms of a license fee that is used to
adopting an AUTOSAR software architecture will auto-
The electrical and electronic (E&E) functions inside a modern vehicle have grown both in number and complexity; this new
recoup the development efforts of designing and creating
matically require the ECU supplier to upgrade the internal
each module, but also in terms of processor load. Each
microcontroller from a 16-bit to a 32-bit processor. Of
software module will take up precious RAM and ROM re-
course, this should not be the natural conclusion, since re-
sources within the microcontroller and also has functions
placing an existing OSEK OS with an AUTOSAR OS SC1
that need to be scheduled and called, that consume valu-
would incur only a minimal additional overhead, and only if
able processor runtime overhead.
the schedule tables feature is utilised.
High-Rate Task Scheduling within AUTOSAR Vector Addresses the Challenges of High-Rate Application Task Scheduling
level of complexity has led automotive vehicle manufacturers and their suppliers to form the AUTOSAR partnership, to define a standardised yet feature-rich software architecture for within the vehicle Electronic Control Units. A common misconception is that high-rate application tasks cannot be scheduled within an AUTOSAR system. This article explains the mechanisms in place within the AUTOSAR operating system to handle the application scheduling requirements and how a successful configuration of the OS allows the software engineer to continue running the high-rate task schedules within an AUTOSAR system.
6/48
The Drivers for AUTOSAR
AUTomotive Open System ARchitecture (AUTOSAR) devel-
In recent years, the electrical and electronic (E&E) func-
opment partnership; where their mutual goal has been to
tions inside the vehicle have grown exponentially, both in
define a common and standardised software architecture
number and complexity. This trend has been driven by a
for use within the vehicle ECUs, that would ultimately pro-
number of factors within the automotive industry, includ-
vide the software features, mechanisms and support nec-
ing an increased demand for E&E-based end-customer
essary to meet the higher demands of the vehicle’s underly-
features, the advent and proliferation of ADAS systems
ing E&E architecture.
and increasingly demanding legislation in diagnosing E&E
Before AUTOSAR was defined, the primary focus of the
system faults and Electronic Control Unit (ECU) failures.
vehicle manufacturers for an ECU’s embedded software
The newest vehicle functions have reached such a level of
was often limited to the network communication stack and
complexity that traditional automotive ECU capabilities
diagnostics. But with AUTOSAR, the underlying software
and supplier development methods can no longer fulfil the
within an ECU has undergone significant expansion;
demands imposed by the modern vehicle E&E architecture.
AUTOSAR “Basic Software” covers not only areas such as
In 2003, this increasing level of complexity led automotive
network communications for CAN, LIN, FlexRay, Ethernet
vehicle manufacturers and their suppliers to form the
and diagnostics protocols, but also now includes system
Figure 1: AUTOSAR OS Scalability Classes
6/49
High-Rate Task Scheduling within AUTOSAR
However, the software engineer now has the option to up-
Cat2 interrupts are normally used to schedule all the tasks
Conclusions
grade the operating system to include timing and/or mem-
of the Basic Software and application level software com-
The AUTOSAR standards have reached a new height, but
ory protection features, with just a simple selection within
ponents, where the AUTOSAR modules are specified to use
will continue to grow and evolve to meet the today’s latest
the required Basic Software configuration. The lead-time
the AUTOSAR OS and API (application programming inter-
vehicle E&E requirements. For ECU software developers,
associated to develop these features no longer has to be a
face). Where the application has a specific high-rate task
embracing AUTOSAR in addition to enhancing their appli-
hindrance, or even a consideration, since the OS is available
scheduling requirement, the software engineer can make
cation features is often considered to be just one further
as a commercial off-the-shelf (COTS) component. If all the
use of the AUTOSAR Cat1 interrupt, and hook the applica-
burden that is too often undertaken only if mandated by
AUTOSAR Basic Software modules are handled in a similar
tion task directly into the microcontroller’s interrupt table
the vehicle manufacturer. The proliferation of AUTOSAR
manner, the inclusion of all the new AUTOSAR features can
using the configuration tool. The Cat1 interrupts are essen-
architectures into powertrain areas has been particularly
become technically trivial, however a significant and visible
tially “invisible” to the rest of the AUTOSAR system.
slower than in other domains (such as body and chassis ap-
impact to the processor load and memory requirements
Cat1 interrupts offer a powerful way to interact with the
plications) with one reason being the concern of handling
would immediately be observed.
hardware directly, and therefore a degree of care and dili-
the high-rate task scheduling demands in addition to all
gence must be exercised when utilising this type of inter-
the new AUTOSAR features.
Scheduling a High-Rate Application Task
rupt; the main advantage is that the latency of the inter-
However, the mechanisms to handle such demands have
Just like the misconception that an AUTOSAR software ar-
rupt is very low, and hence the required high-rate task
already been considered and addressed by the AUTOSAR
chitecture inherently requires a 32-bit processor, a similar
scheduling can be achieved. However the normal protec-
standards and many AUTOSAR applications are success-
misunderstanding occurs that high-rate application tasks
tions offered by the AUTOSAR OS are not present, and
fully running high-rate task schedules using the OS Cat1
cannot be scheduled within an AUTOSAR system. Many
therefore the interactions from within the Cat1 interrupt
interrupts. By analysing the processor load within such sys-
typical automotive applications, especially within the power
with the rest of the system have to be carefully considered
tems, Vector have observed that in many cases the high-
train domain, require tasks that can run at rates of every
prior to implementation.
rate task scheduling can still be achieved whilst also run-
100 microseconds (10 kHz) or even faster. Such a challeng-
Another aspect that has to be thought out is the allocation
ning the feature-rich AUTOSAR Basic Software.
ing scheduling requirement puts a very high demand on the
of the interrupt priorities across the system. The AUTOSAR
But inevitably the additional features that are provided
AUTOSAR OS, and in turn on the microcontroller process-
OS is a fully pre-emptive operating system and therefore
within the AUTOSAR Basic Software and AUTOSAR OS will
ing load.
the AUTOSAR application tasks may interrupt each other.
bring further demands in load onto the processor, and
For these purposes, the AUTOSAR OS provides two types
But it would be unacceptable for an AUTOSAR task to be
therefore new differentiators have emerged within the em-
of interrupt “category”: >>Cat1 interrupts are “unsupported” by the AUTOSAR OS.
allowed to interrupt, or block, the high-rate scheduled task
bedded software market. The scalability, configurability,
and therefore the priorities need to be allocated such that
efficiency and optimisation of each new AUTOSAR module
This means that the code to get safely into and out of
the high-rate task has the highest priority in the system.
has to be considered when sourcing AUTOSAR Basic Soft-
the interrupt handler is not generated by the AUTOSAR
This means that the high-rate task can interrupt any other
ware as off-the-shelf commodity parts.
task in the system, including the AUTOSAR OS, and every
Adopting AUTOSAR continues to be a concern for many
OS and has to be generated in another way. [1] >>Cat2 interrupts are supported by the OS. This means
other interrupt in the AUTOSAR system must be at least
ECU suppliers, often heightened by the perception of the
that the OS’s code generator and libraries abstract the
one priority level below that of the high-rate task, this is
complexity it can bring. But the complexity is inherently
interrupt from the hardware in a portable way. [1]
termed the “system interrupt level”.
present within the system already, driven by the end-cus-
Steve Waldron, Vector GB Ltd. Local Product Line Manager for the Embedded Software Product Line
Tom Dalek, Vector GB Ltd. Software Engineer for Embedded Software
Alex Ghinet, Vector GB Ltd. Senior Software Engineer for Embedded Software
tomer’s feature requirements and the underlying E&E architecture necessary to support those required features. AUTOSAR only provides the mechanisms and structures necessary to manage the already existing complexity; therefore an AUTOSAR system should not be viewed as a problem – but rather, that it provides the solution. Image rights: Vector Informatik GmbH / Vector GB Ltd. Literature: [1] Explanation of Interrupt Handling in AUTOSAR, sourced from www.autosar.org on 09/07/2015: www.autosar.org/ fileadmin/files/releases/3-2/software-architecture/general/auxiliary/AUTOSAR_InterruptHandling_Explanation.pdf Links: Website Vector: www.vector.com Figure 2: Example High-Rate Task Scheduling within an AUTOSAR System
6/50
Vector AUTOSAR Solution: www.vector.com/autosar/
6/51
tions and transferred data elements . The virtual functional bus combines these ports on an abstract level. After distributing the software components to ECUs, the abstract signals of the virtual functional bus are mapped to specific network signals, PDUs, and frames, and are thereby assigned to a physical network. Use of AUTOSAR in Heavy Duty Vehicles The first trucks to feature an AUTOSAR-based EE architecture have already been on the roads for several years. Individual ECUs from other branches of industry are also already based on this standard, e.g. engine controllers for diesel engines. The first agricultural machine producers are currently adapting their processes to AUTOSAR and have already developed initial pre-production ECUs. Considerable efficiency gains have been achieved in implementation by systematic migration to AUTOSAR methodology. The use of AUTOSAR in the heavy duty vehicle industry was enabled by a step-wise extension of the basic software to include J1939 protocols (Figure 2). In 2009, the cornerstone was laid for this effort when the J1939 Transport Layer (J1939Tp) was specified in AUTOSAR 4.0.1. Four years later, AUTOSAR 4.1.1 introduced meta data, and thereby the ability to access address information in the CAN IDs from higher layers of the basic software – which is important for
New Opportunities with AUTOSAR
Figure 1: Excerpt from an AUTOSAR architecture extended for agricultural machines
AUTOSAR has been gradually adapted for use in heavy duty vehicles since 2009 and is already being used in the produc-
message regardless of its sender, which is necessary for correctly responding to a request. The J1939 Request
tion of some truck model series. AUTOSAR is currently being introduced in agricultural machines, and with a few extensions of AUTOSAR this could become a success story as well.
J1939. Meta data makes it possible to handle or route a
Manager (J1939Rm) was introduced as an additional BSW the RTE (Runtime Environment), which accesses the basic
module to perform this task. The J1939 Network Manage-
software for external communication. Figure 1 shows some
ment (J1939Nm) was added for address arbitration, as
of the basic software that is relevant to J1939 applications
was the J1939 Diagnostic Communication Manager
as well as the RTE and SWCs of the application layer.
(J1939Dcm) which handles J1939 diagnostics together with
For several years now, after the implementation of AUTOSAR
es over to this methodology opens up the opportunity for
by truck producers, manufacturers of agricultural and
rethinking the entire ECU architecture and therefore opti-
construction machines have also expressed interest in
mizing it for modular usage of all of its components – hard-
Software Component Model of AUTOSAR
Currently, AUTOSAR is encountering its limits in fully dy-
AUTOSAR. Compared to the automotive and truck indus-
ware and software. This makes the AUTOSAR methodolo-
The software components (SWCs) of AUTOSAR are em-
namic address allocation (Figure 3), which is widely used in
tries, they build even more vehicle variants with even lower
gy an important driver of innovation.
bedded in a hierarchy of compositions. The SWCs function-
agricultural and construction machines and is a prerequi-
ality is implemented by runnables. SWCs define their com-
site for communication on the ISOBUS. Also to be improved
munication needs by interfaces (Ports) which group opera-
is the ability to handle several multiplexors in proprietary
production volumes. Therefore, the problem of rising costs with the increase of electronics in new vehicles is particu-
The Architecture of AUTOSAR
larly difficult in this area. To remain competitive, it is crucial
There were two primary motivations for developing the
for agricultural and construction machine manufacturers
AUTOSAR standard. The first goal was to standardize the
to re-use entire ECUs and individual functions implement-
hardware and protocol drivers, which was achieved by
ed in software as often as possible. AUTOSAR was devel-
specifying the basic software modules (BSW modules).
oped precisely for such requirements, and therefore it im-
One benefit of the basic software is to save costs by using
poses itself as the natural choice for this domain.
standard software. Second, it makes it easier to exchange
the extended Diagnostic Event Manager (DEM).
an ECU’s hardware.
6/52
Conceptual Advantages of AUTOSAR
The next goal of AUTOSAR was to break down complex
The software component model of AUTOSAR promotes
functions into manageable units. This was achieved by im-
re-use of individual functions. To re-use entire ECUs, an
plementing software components (SWCs) that communi-
sophisticated variants handling method and the option of
cate via an abstract channel known as the virtual function-
reconfiguration (post build) are available. However, the
al bus (VFB). The actual communication relationships are
greatest advantages are based on systematic use of
determined by the distribution of components to ECUs.
AUTOSAR methodology. Converting development process-
The entire communication is implemented at runtime by
Figure 2: J1939 milestones in AUTOSAR
6/53
Key Properties of ISO 11783 / ISOBUS ISO 11783 was developed with the goals of combining any desired tractors with any implements over the ISOBUS and of promoting new developments in agricultural technology such as “precision farming.” The standard is based on SAE J1939 with fully dynamic addressing, and it adds specialized components as well as satellite navigation from NMEA 2000. The most Figure 3: Dynamic address allocation on the ISOBUS
important components are: > Virtual Terminal: for monitoring and manually controlling implements > Task Controller: for automatically controlling implements based on position data.
messages (PropA, PropA2, PropB) and the transport protocols of NMEA2000 and ISO 11783. There is also no support yet for the protocols of ISO 11783 components such as the Virtual Terminal and Task Controller.
> Tractor Controller: for exchanging data between the vehicle network and implement network. > Sequence Controller: for logging and repeating identical sequences such as turning at the end of the field.
Further Development of AUTOSAR Today, there are already solutions available for fully dynam-
> File Server: for saving the data of other ECUs upon request.
ic address allocation and for the extended transport protocol of ISO 11783 as well as for handling proprietary messag-
Compared to J1939, ISO 11783 uses two additional
es. In these solutions, the CAN Interface (CanIf), J1939Nm,
transport protocols: extended TP for large amounts of
J1939Tp and J1939Rm modules are extended accordingly.
data and FastPacket for navigation data. It also re-
However, these AUTOSAR extensions are only partially co-
stricts diagnostics to the active error and last active
ordinated between different suppliers. Standardization on
error (DM1-DM3).
the level of the basic software would be desirable here. Implementations also exist for the protocols of ISO 11783 components today. Standardization of these protocols in
Translation of a German publication in Hanser automotive,
AUTOSAR could be achieved by “application interface” doc-
November 2015
uments, which just define the interfaces to the application. They would then be implemented by complex drivers (CDD).
Image rights:
Several manufacturers of heavy duty vehicles such as
Vector Informatik GmbH
Caterpillar, CNHi and John Deere have recently become members of AUTOSAR, and this increases the chances that
Links:
dynamic addressing and the lacking protocols will be added
Vector: www.vector.com
to the standard over time. Then there would be no remain-
MICROSAR basic software: www.vector.com/microsar
ing obstacles to implementing AUTOSAR in the area of heavy duty agricultural vehicles and construction machines.
6/54
Dipl. Inf. Martin Schlodder studied computer science at the University of Tübingen and has been employed at Vector Informatik since 2004. He develops J1939 software and is a member of AUTOSAR working groups for integration of J1939. E-Mail:
[email protected]
medium between two functions. As a result, communi-
Model-based Safety Analyses
cation failures are inadequately considered. For example,
ISO 26262 requires that safety analyses be performed on
later redistribution of software functions to different
the system, software and hardware levels, so that design
ECUs in different bus segments might violate system
weaknesses can be detected and actions can be taken to
integrity due to the flawed original assumption –
improve the design. One such analytical method is Failure
without the software developer being aware of it. >>A hardware component exhibits atypically high failure
Modes and Effects Analysis (FMEA). It is used to identify potential failures in individual components and analyze
rates, because it is located in a vehicle area that is
their effects on system goals as well as their probability of
exposed to extreme environmental conditions, such as
occurrence. This type of analysis is well suited to identifying
temperature mechanical vibration or electromagnetic
components that are critical from the perspective of safety
interference. Elevated failure rates were not considered
goals. Nonetheless, the results depend very much on the
in the safety concept.
quality and scope of the modeled system design upon which the analysis is based. When system dependencies
Model-based Functional Safety in E/E System Development The introduction of the international standard ISO 26262 for Functional Safety of Electrical/Electronic Systems in the Automobile has significantly increased awareness of this topic in the industry. As a result, many OEMs and suppliers are seeking approaches that pragmatically fulfill requirements of the standard, while addressing the rising complexity of safety-related functions appropriately. It takes greater work effort to develop safety-critical systems compared to conventional systems. Although constraints remain the same, additional activities related to schedules, resources and costs
A comprehensive approach to system modeling is neces-
are inadequately documented, the results often depend on
sary to give due consideration to such complex interrela-
the individual experience levels and knowledge of engi-
tionships in the design phase. This approach combines all
neers, and this often leads to the problems illustrated in
functional and nonfunctional requirements in one data
the examples above.
model as well as the logical system design, network archi-
Comprehensive modeling of the system is an optimal pre-
tecture and software and hardware component architec-
condition for performing safety analyses. In conducting
tures. Similarly, it is necessary to consider the wiring har-
these analyses, the safety expert accesses information
ness and the topological distribution of components and
directly from the model. Dependencies, especially between
the wiring harness in the vehicle (Figure 1). In this process,
different architecture levels, may be automatically ana-
it is important to be able to describe the interdependencies
lyzed, and their effects on system safety evaluated. Actions
between different architecture levels as well as domain-
derived from the analysis are implemented directly in the
specific attributes of the modeled artifacts (e.g. bus laten-
model, and they are linked to the relevant analysis. This
cy times, hardware failure rates or temperature ranges of
produces traceability between the design, analysis and af-
instalation location). Based on this data, analysis – which
fected safety goals, which are absolutely essential to pro-
may be performed semi-automatically – can then be used
vide the required safety verification and conduct impact
to formulate and answer questions such as: “Will wires
analyses in response to system changes. Close intermesh-
transmitting signals relevant to the safety concept be
ing of the system design, safety analysis and design of the
routed in areas that are at risk of damage in a crash?”
safety concept makes it possible to immediately analyze and evaluate the effects of model changes. This eliminates
are unavoidable. Existing development, analysis and test methods and their associated tools are often fragmented and
the need for time-consuming re-designs, which would other
can only be integrated in a uniform process with great effort.
wise be unavoidable in the case of sequential handling of the design and then the safety analysis. In addition, multiple implementation variants of a system may be compared
7/0
Consequently, new approaches are needed to enable func-
implementation of these safety requirements must be as-
and evaluated. This makes it possible to perform system
tional safety as an integral component in the development
sured by a suitable combination of reviews, analyses and
optimization that incorporates safety-technical perspec-
of E/E systems. It is important to consider all levels of sys-
tests.
tives in an early phase of system development (Figure 2).
tem designs (Figure 1) and assure that safety goals of the
The attainment of system safety goals depends on many
systems are verifiably implemented according to the stan-
different factors. One example: faulty programming of
Product Line Approach Yields Increased Efficiency
dard.
software functions or random hardware failures in critical
From a system viewpoint, personalizing vehicles, i.e. offer-
components. As recommended in ISO 26262, such isolated
ing different variants and configurations, leads to a num-
Comprehensive Perspective of System Architectures
failures can be avoided relatively easily, or can at least be
ber of variants that is simply unmanageable. The safety
A key requirement of all current safety standards in auto-
detected and overcome by current development methods.
engineer is immediately faced with the challenge of provid-
motive and non-automotive industries (e.g. IEC 61511 for
It becomes more problematic when safety goals are affect-
ing the required safety validation for each system variant.
the process industry, IEC 61513 for nuclear power plants,
ed by a combination of different system factors on differ-
One way to confront this challenge is to use a product line
EN 50128 for railway systems) is that it must be verified
ent architecture levels. However, in the case of complex
approach. This approach is based on the analysis (domain
that the developed system concept fulfils system safety
systems, such interdependencies can hardly be revealed by
analysis) of variant-based systems (product lines) with re-
goals. Safety goals are typically identified in hazard and
conventional, document-based design methods. Here are
gard to identical parts (commonalities) and differences
risk analyses on the functional system level. The functional and technical safety requirements derived from the safety
two examples of typical design errors: >>During software development, incorrect assumptions
goals are then allocated to system components. Correct
are made about the integrity of the communication
Figure 1: Model-based system design: Comprehensive perspective of all elements of the system architecture and their dependencies
(varia-bilities). Identifying commonalities provides a foundation for re-using them over a number of products (vehicles). Furthermore, the work only needs to be performed
7/1
Model-based Functional Safety in E/E System Development
once to create requirements analyses, implementations or
for understanding and mastering complex systems, which
Translation of a German publication in ‘Automobil Elektronik’,
tests.
in the end leads to safe systems. The model-based ap-
issue 2/2012
To make the reusability concept feasible for the develop-
proach promotes the increased efficiency to compensate
ment of safety-critical systems, the product line approach
for the additional work effort caused by safety relevant
Image rights:
must be extended to hazard and risk analyses as well as to
activies (analyses, implementation of actions resulting
Vector Informatik GmbH
safety concepts. These analyses and concepts are available
from them and safety validations). The re-use of entire
for re-use, provided that they relate to a common set of
portions of the safety architecture avoids work steps that
Links:
features. Technical safety requirements for specific vehicle
are repeated one or more times, and this leads to further
Home page Vector: www.vector.com
projects are derived from the functional safety concept.
increases in efficiency.
Solutions for Functional Safety:
For example, specific vehicles are characterized by specific
The all decisive factor for success is the availability of
www.vector.com/functional-safety
operating states, system architectures, etc. (Figure 3). Apply
proven tool support for implementing the paradigm shift
Product information PREEvision:
ing domain analysis to the technical safety requirements
described here in daily practice: from a document-centered
www.vector.com/preevision_en
can make some of these requirements available for re-use.
approach to a model-based approach. A key requirement
To maximize the added value of re-use, domain analysis
for a tool is its suitability for describing complex systems by
can also be extended to system components (software
means of a related semantic data model. But domain-spe-
components, hardware components). Performance of the
cific graphic notations and support in analyses as well as
safety validation is supported by re-use of a portion of the
performance of safety validation are also absolutely essen-
argumentation structure (safety case argumentation struc-
tial. Collaboration on large teams results in further require-
ture). Assumptions about the specific vehicle environment
ments. The provision of a collaboration platform for data
are formulated as requirements whose implementation or
storage (single source principle) and data exchange among
validity must then be analyzed for the specific context.
all project participants. In this process, competencies and
A model-based approach is a prerequisite for performing
responsibilities must lend themselves to modeling by a
variant-specific analyses and consistency checks. This ap-
rights and roles concept. Chronological traceability (history
proach ensures, for example, that all actions listed in the
of versions) requires integrated version and configuration
safety validation and technical requirements derived from
management.
the re-used safety concept can actually be implemented in
In its PREEvision product, the company Vector is offering a
the specific vehicle. If a redundancy that is provided in the
proven tool for model-based systems engineering that has
safety concept were to be lacking, for example, this would
been on the market for over five years. PREEvision also pro-
be detected as an unfulfilled requirement in a variant-spe-
vides assistance in the areas of testing (test data manage-
cific consistency check.
ment), planning (product and release management) and
Dr. Simon Burton studied Computer Science at the University of York in England. He earned his doctorate degree in York as well with a thesis on Specification and Testing of Safety-Critical Systems. Focal points of his career include the introduction of systems engineering and model-based approaches in developing embedded, safety-critical systems. In 2006, he joined the Vector Group where he has served in the areas of safety consulting, product management and business management of the Automotive Solution. Albert Habermann studied physics at the Ludwig-Maximilians University in Munich. Focal points of his career include the introduction of model- based methods to software development and testing. In 2006, he joined Vector where he is employed as a project manager in the Customer Service area for the PREEvision architecture and systems engineering tool.
change management. In its latest version, PREEvision supSummary
ports an ISO 26262 conformant approach to modeling,
Model-based methods and a comprehensive approach
analysis and testing of functional safety concepts.
(Systems Engineering) give the system developer a method
Figure 2: Safety round-trip engineering: Safety analyses and modeling of the safety concept and safety design are performed in one model. This makes the dependencies and effects of changes immediately recognizable, so that they can be considered in further analysis.
7/2
Figure 3: Re-use: Common elements of the safety architecture are re-used for different vehicles.
7/3
The “standard case” category includes systems with mod-
Protection against Communication Errors
erate ASIL content, where the interaction between the dif-
ISO 26262 lists relevant error patterns in the exchange of
ferent contents is rather low. In these cases, separating the
information, and AUTOSAR has defined algorithms for de-
partitions is implemented very efficiently by separate ele-
tecting them by an end-to-end protection. As in program
ments. Barriers are set up between the partitioned con-
flow, the goal is to reliably detect each occurring error and
tents; they prevent – or at least detect – propagation of
change the system to a safe state. Monitoring is performed
errors with sufficient probability and report them to the
by inserting sequence numbers and a checksum.
ASIL software. This means that only the barriers and safe-
To avoid having to assume a safe RTE (Runtime Environ-
ty-related software need to be developed to the relevant
ment), the E2E Protection Wrapper and E2E-Lib modules
ASIL (Figure 2). In MICROSAR Safe – basic software (BSW)
perform monitoring above the RTE in a safe partition of
developed jointly by Vector Informatik GmbH and TTTech
the application software. In MICROSAR Safe, these two
Automotive GmbH – these protective mechanisms are
modules are contained in option SafeCOM.
available up to ASIL-D.
SilentBSW – Silent AUTOSAR Basic Software for Safety-related ECUs Coexistence of Safety-related and Non-safety-related Software in one ECU by Protecting Memory Areas
Coexistence with a Low Portion of Safety-related Protection against Memory Violations
Software
The Memory Protection Unit (MPU) of the microcontroller
If the portion of ASIL software is low, it may make sense to
is used to limit write access to the memory areas of its own
have the ASIL software protect itself against undesirable
partition. The software that drives the MPU and executes
memory changes. The undesirable modification might be
the context switch must support the highest assigned
detected, or even corrected, by the following measures
ASIL. This software is part of an AUTOSAR operating sys-
(Figure 3): >>Redundant and possibly diversified computation –
tem per Scalability Class 3 or 4 and must be developed to ASIL-D. This function is part of MICROSAR Safe and known as SafeContext.
including validation of the ASIL software’s algorithms >>Redundant and possibly diversified storage of data >>Deactivation of interrupts in critical areas, e.g. in areas
Protection against Violations of Time Behavior and
in which comparisons and decisions are made.
In future vehicles, most ECUs will be “Mixed-ASIL systems” that contain both safety-related functions and functions
Execution Sequence
without safety relevance. This article presents strategies for efficiently implementing these functions based on AUTOSAR.
Errors in the QM software must not interfere with proper
If it is only possible to detect errors but not prevent them,
One solution is SilentBSW – an AUTOSAR basic software that monitors itself and blocks prohibited write accesses to
timing behavior of the tasks of the ASIL software. This is
the ASIL software must take appropriate measures to put
safety-related software.
achieved by monitoring the defined execution sequence
the system in a safe state. Self-protection against memory
and time intervals between different functions of the ASIL
changes is implemented in the ASIL software for the spe-
software. AUTOSAR 4.0 defines functions for this purpose.
cific project. The methods described above are adopted for
In conjunction with a safe hardware watchdog, the soft-
program flow and communication, because no self-protec-
quirement would mean that the entire ECU would have to
ware detects any violation of requirements and changes
tion is possible in these areas.
AUTOSAR addressed the topic of “functional safety” early
be developed in accordance with ASIL-D.
the system to a safe state. This does not prevent errors,
on. Current versions of the AUTOSAR specification [1] con-
To avoid this “ASIL lift-up effect” [3], ISO 26262 allows the
but their occurrence is detected. This approach has proven
tain a number of concepts that support the development
coexistence of sub-elements with different ASIL levels. This
to be effective within typically allowable error reaction
of safety-related ECUs. Examples are the end-to-end pro-
coexistence requires verification that there are no undesir-
times. MICROSAR Safe includes this functionality under
tection for exchanging information and the program flow
able interactions between sub-elements. Partitioning is a
the name SafeWatchdog.
monitoring with a watchdog. In defining these concepts,
proven method for implementing this “freedom from inter-
steps were taken to support ECU developments in accor-
ference” for software. The following aspects must be con-
dance with ISO 26262 [2].
sidered in this context:
AUTOSAR and ISO 26262
1. Memory accesses Software Development for Safety-related ECUs
2. Timing behavior and execution order
AUTOSAR supports the distribution of functions to mul
3. Exchange of information
tiple ECUs. This simplifies functional development, which
7/4
can be conducted without regard to the mapping of func-
“Standard Case” of Coexistence
tion units on specific ECUs. One consequence, however, is
ECUs containing both safety-related and non-safety-relat-
that a disproportionately high number of ECUs are then
ed functions are known as Mixed-ASIL systems. For pur-
classified as needing to fulfill safety requirements (Figure 1).
poses of simplification, in this article any software with a
These ECUs would have to be fully developed according to
low ASIL is referred to as QM software, and software with
the highest ASIL (Automotive Safety Integrity Level) of
a higher ASIL is referred to as ASIL software. A prerequisite
their requirements, even if the vast majority of its functions
for the use of ASIL software is that the hardware design
might not be safety-related. Just a single ASIL-D safety re-
must be adequate for the maximum required ASIL.
Figure 1: Example of a Mixed-ASIL system with function mapping to multiple ECUs
Figure 2: Barriers prevent errors from being propagated to the ASIL software
7/5
SilentBSW – Silent AUTOSAR Basic Software for Safety-related ECUs
Coexistence with Strong Interaction
ficulty here lies in a unique property of the basic software:
The article is based on a speech of Günther Heling at the
The method of protecting against memory violations based
Parts of the program code are generated, and it is not fea-
VDI conference Baden-Baden-Spezial, VDI report 2172
on an MPU, which is described above, is a very powerful
sible to develop configuration and generation tools per
mechanism for implementing any combination of partitions
ISO 26262.
References:
of different ASILs on an ECU. However, the required con-
The solution is to check the entire code after generation.
[1] AUTOSAR GbR: http://www.autosar.org
text switching between the partitions results in runtime
This is not performed by tests, rather by a specially devel-
[2] International Organization for Standardization (ISO),
overhead that can become critical. This could happen, for
oped code checker. This validation covers the vast majority
ISO 26262-1 bis ISO 26262-9, Road vehicles – Functional
example, if a large number of signals are exchanged syn-
of error patterns. The remaining error patterns are covered
safety ISO 26262-1:2011(E) up to ISO 26262-9:2011(E), First
chronously between the ASIL application software and the
by code inspections or runtime checks.
Edition 2011-11-15 [3] Dr. Poledna, S et.al.: Ein ASIL D Plattformsteuergerät
QM basic software, and it is not possible to group the signals.
Summary and Conclusion
für eine elektrische Hinterachse mit Fahrdynamikfunktio
In such cases, it is advantageous to have the QM basic soft-
Approaches are already available today for developing ECU
nalität; VDI-Bericht Nr. 2132, 2011 (English translation of
ware run in the same partition as the ASIL application soft-
software per AUTOSAR and ISO 26262 up to ASIL-D. They
the speech title: An ASIL D platform ECU for an electric
ware. But that is only possible if the basic software was
include methods for the especially relevant Mixed-ASIL sys-
rear axle with driving dynamics functionality; VDI report
developed for the ASIL of the application software. The de-
tems, as well as the new SilentBSW approach from Vector,
No. 2132, 2011)
velopment effort required for this is often not suitable, be-
which significantly reduces the execution time require-
cause the requirements of the actual functionality of the
ments for some application cases.
basic software are typically not classified as safety-related.
It is not necessary to assume that every requirement of the
This applies to sending out signals, for example, because an
basic software must be generally classified as safety-
end-to-end validation of the communication is still always
related. Rather, it is much more important to implement
necessary to detect errors in bus transmission.
individual requirements – which are derived from the safety
Therefore, one highly efficient approach is to leave the
concept for an ECU – in the basic software at the specific
basic software on the QM level and enable coexistence with
ASIL that is needed.
the ASIL software without the use of an MPU. MICROSAR
Dr.-Ing. Günther Heling, Vector is Global Product Line Manager for Embedded Software at Vector Informatik GmbH in Stuttgart.
Dipl.-Ing.(FH) Jochen Rein is Manager Product Management and Sales for Embedded Software at Vector Informatik GmbH in Stuttgart.
Safe offers this type of solution under the name SilentBSW – which is a non-interfering basic software. To prevent undesired overwriting of memory cells of the Dipl.-Ing.(FH) Patrick Markl, Vector is Team Leader Concept Development Embedded Software at Vector Informatik GmbH in Stuttgart.
ASIL software by the QM software (Figure 4), it is verified for each write command of the QM software that the write access is performed within a valid memory range. One dif-
Figure 3: The ASIL software protects itself from errors
7/6
Figure 4: The QM software itself blocks unallowable write accesses to the memory of the ASIL software
7/7
is that they must conform to the principle of freedom from
the switch (Figure 2). This switch is only executed by the
interference ([1] Part 9, section 6.4).
operating system and is safety-related. Therefore, the
Freedom from interference of software components is
AUTOSAR operating system MICROSAR OS SafeContext
efined by three properties: d >>Safe memory accesses
was assigned ASIL D classification and was developed in processes defined for ASIL-D in ISO26262.
>>Correct time execution >>Safe data exchange
Comprehensive Validation Concept It is important to monitor the program flow in safety-related
Practical Implementation of Mixed-ASIL Systems A Certified Operating System Simplifies the Development of Safety-related Software The ISO 26262 standard describes a recognized and standardized process for developing safety-related ECUs in the automotive field. However, only parts of the software in these ECUs are safety-related. The goal is to restrict the additional, intensive development efforts for these safety-related components. It is possible to set up an ISO-conformant mixed-
A component’s freedom from interference can be verified
systems. The Watchdog Manager specified in AUTOSAR
by classic verification measures, e.g. by code reviews. There
(Figure 1) is used for this purpose. This module, which supple-
are also approaches in which a specially developed code
ments MICROSAR OS SafeContext, is available in the form
checker is used to check the freedom from interference of
of the SafeWatchdog [3] developed by TTTech Automotive
the basic software [2]. Other measures may be taken in the
GmbH, which is qualified to ASIL D. As the name suggests,
software to ensure protection against hardware-related
this component controls the hardware watchdog, and it
disturbances as well.
safely ensures a reset of the ECU in case of error. In addi-
A modern AUTOSAR operating system like MICROSAR OS
tion, this component monitors for correct time flow of the
SafeContext (Figure 1) offers protection against faulty
application’s tasks. Developers can set a number of param-
overwriting of memory contents. The protection is achieved
eters for the monitoring such as program flow, cycle times,
by partitioning each functional group into a so-called OS
minimum/maximum execution times, etc.
application. Each OS application’s data are allocated in
The third requirement for freedom from interference, which
separate memory partitions. Along with the application
is implementation of reliable communication, is fulfilled by
data, context-related data such as stacks and the contents
end-to-end protection (Figure 1). With the help of the
of important registers are also located in such a memory
E2ELib [4] specified in AUTOSAR, the SafeCOM product
partition. Access to these memory partitions is prevented
protects the data to be transmitted using a CRC and se-
by a Memory Protection Unit (MPU), which is part of the
quential message numbers. Strictly speaking, this does not
microprocessor hardware.
ensure safe communication, rather just “integrity” in com-
When switching the running task or the Interrupt Service
munication. Software cannot protect against data failure
Routine, the operating system executes a context switch.
due to hardware errors, e.g. a bus line break. To ensure safe
Here, the context data is stored, and the MPU is recon
communication, additional measures must be taken in the
figured so that it only enables the memory partition for
hardware, e.g. in the form of redundant buses.
the task or Interrupt Service Routine that is active after
ASIL system, which may contain both ASIL functions and functions without qualification, using an advanced AUTOSAR operating system and two other basic software modules.
The ISO 26262 standard is increasingly being used to de
The approach of using mixed-ASIL systems provides a solu-
velop safety-related ECU software. At the beginning of a
tion. In this case, the functional groups are isolated from
standard-conformant development process, the developer
one another by suitable protection measures, so that they
performs a hazard analysis and risk assessment of the sys-
cannot interfere with one another. This reduces the devel-
tem under development. The developer establishes safety
opment effort for the individual functional groups to what
goals and assigns each of them a specific Automotive
is required for their specific ASILs.
Safety Integrity Level (ASIL), ranging from A to D, based on
The protection mechanisms needed are available in the
the probability the error will occur, the severity of damage
form of a modern AUTOSAR operating system and two
that could result and the ability of the driver to control the
other basic software modules which the ECU manufac
vehicle in case of defect.
turer does not need to develop separately.
Assignment of ASILs to all software elements generally
7/8
results in functional groups with different ASIL classifica-
Technical Safety Concept
tions. In principle an ECU’s entire software must be devel-
Developers must ensure that the overall system fulfills
oped to the highest ASIL determined for one of these func-
their safety requirements. None of the system’s software
tional groups. This intensifies the development effort to an
components may put fulfillment of these safety require-
extreme, because even non-safety related software must be
ments at risk. Therefore, the only safety requirement for
developed to the high requirements of the safety process.
software components without safety-related functionality
Figure 1: Layout of pro tective mechanisms in the AUTOSAR architecture
7/9
Practical Implementation of Mixed-ASIL Systems
Integration of Application Software and Operating
MICROSAR OS SafeContext, used together with the Safe-
System
Watchdog and SafeCOM basic software modules, provides
In the ISO standard, safety-related components developed
an up-to-date and safe development foundation for safe-
by an external supplier and supplied to the ECU manufac-
ty-related ECUs. In particular, it can be used to cost-effec-
turer are referred to as “Safety Elements out of Context”
tively implement mixed-ASIL systems.
(SEooC). They include the operating system discussed
Besides protecting the application software, the safety
above as well as the watchdog manager and the E2ELib.
process must also protect all of the basic software. Vector
During development, the suppliers of such components
offers a variant developed in conformance to ISO 26262
must make assumptions about the expected safety goals
which is distinguished by its ability to achieve the safety
without familiarity with the ECU project. Therefore, as part
goal “freedom from interference in relation to memory
of integration work ECU developers must check whether
access”.
Steffen Keul (Dipl. Computer Science) is Product Management Engineer for Functional Safety at Vector Informatik GmbH
Dr. Helmut Brock (Doctor of Engineering) is Product Manager Operating Systems at Vector Informatik GmbH
the safety goals assumed for the supplied SEooC are sufficient for achieving the safety goals of their projects. More-
Translation of a German publication in the special edition
over, the ECU developer is responsible for following special
“Funktionale Sicherheit” of Elektronik automotive, July/2013
integration instructions for the supplied software module. Therefore, each SEooC is supplied together with a safety
Image rights:
manual, which contains the integration instructions and
Vector Informatik GmbH
assumptions about safety goals. At first, this may sound like more work. However, upon
References:
closer examination, it becomes clear that a similar level of
[1] ISO 26262 - Road Vehicles - Functional Safety, 2011
effort must be planned for integrating components that
[2] G. Heling, J. Rein and P. Markl, “Koexistenz von sicherer
are developed in-house, but the advantage of supplied
and nicht-sicherer Software auf einemSteuergerät” (“Co-
components is that the effort required for creating these
existence of safety and non-safety software in one ECU”),
components is eliminated. Overall, this yields significant
ATZ special electronics issue of electronica, pp. 62-65,
work savings.
November 2012 [3] AUTOSAR, “Specification of Watchdog Manager” V2.3.0
Outlook
[4] AUTOSAR, “Specification of SW-C End-to-End Com-
The TÜV Nord organization has certified the MICROSAR
munication Protection Library” V3.0.0
OS SafeContext operating system developed by Vector for the TMS570 microcontroller, making it the first AUTOSAR
Links:
operating system to be certified to ASIL D. This implemen-
Website Vector: www.vector.com
tation is currently being transferred to other platforms.
Product Information MICROSAR Safe: www.vector.com/
They include multi-core processors which are being used
vi_microsar_safe_26262_en.html
increasingly.
Figure 2: The MPU in the hardware protects the memory partitions from unauthorized access. Reconfiguration of the MPU is performed by the operating system.
7/10
7/11
7/12
7/13
7/14
7/15
Safe ECUs According to ISO 26262
Solutions for Functional Safety
Benefit from Vector’s solution for functional safety in your ECU development projects: > Develop and analyze safety-related E/E architectures with PREEvision > Implementation of safety requirements up to ASIL D in ECUs using MICROSAR Safe
> Training and coaching to qualify technical specialists and managers, and consultation on safety-related development projects Information and downloads: www.vector.com/safety
Vector is your competent partner in developing safety-related ECUs – based on experience, dedication and practice-proven products.
7/16
Vector Informatik GmbH | Germany · Austria · Brazil · China · France · India · Italy · Japan · Korea · Sweden · UK · USA | www.vector.com
pendent of the function to be performed, and they are de-
dles monitoring of time requirements by deadline monitor-
termined by the required diagnostic coverage (DC) for a
ing. As soon as safety-related data is exchanged between
specific ASIL.
more than one ECU, communication protection comes into
Microcontroller manufacturers often set specific require-
play. AUTOSAR offers an effective safety mechanism for
ments based on their safety analyses. For example, a DC
this purpose in the form of end-to-end protection (E2E).
for ASIL D requires built-in self-tests (BITs) that are exe-
Products from Vector that are certified up to ASIL D are
cuted periodically by the software. Generally, starting with
available for implementing these comprehensive measures.
ASIL B the probability of occurrence of so called Single
Is This What the Future Will Look Like? Implementing Fault Tolerant System Architectures with AUTOSAR Basic Software Highly automated driving adds new requirements to existing safety concepts. It is no longer sufficient to simply deactivate a function to reach a safe state. In the future, a safe state will require energy and active functionality. This article shows available mechanisms and explains how they can be modularly combined to attain an effective safety concept. It
Event Upsets (SEUs) must be considered. Microcontrollers
Transition to Fault Tolerant Systems
in lock-step mode and memory with error detection and
For cost reasons, today’s hardware is designed to be nearly
correction codes (ECC RAM, ECC ROM) offer effective pro-
redundancy-free. Therefore, a hardware fault generally
tection against SEUs. Both safety mechanisms are realized
leads directly to a serious functional degradation up to
in the hardware, are nearly transparent to software devel-
complete failure. On the other hand, mature methods exist
opment, and are therefore very efficient solutions.
for quantifying hardware failures, such as those defined in
The developer normally implements additional mechanisms
IEC 62380 and SN29500, which permit predictions of the
in the application to perform functional monitoring. They
target failure rate [2].
include monitoring tasks for sensors and actuators, as well
It is often difficult to quantify software faults, since they
as limiters and program flow monitoring (logic monitor-
are exclusively systematic [3]. Timing protection is a suit-
ing). Program flow monitoring can be achieved with an
able safety mechanism for boosting fault tolerance with
AUTOSAR watchdog, for example.
respect to software faults. Timing protection guards
Functional monitoring and microcontroller integrity are de-
against such faults as infinite loops in software compo-
fined and implemented according to the specific project.
nents that prevent execution of the actual functionality. In
However, there are also mechanisms that are used in near-
timing protection, the developer assigns time budgets for
ly every safety-related ECU and are independent of func-
the execution times of tasks and interrupt routines and for
tionality and ASIL. Almost every ECU with ASIL software
the blocking times of interrupts and resources. The time
also executes QM software. To ensure coexistence accord-
intervals between tasks and interrupt routines are also
ing to ISO 26262, memory separation and monitoring of
monitored (Figure 2). In case of a fault, the AUTOSAR oper-
time constraints are needed [1]. Memory partitioning is re-
ating system can terminate the task or interrupt routine
alized by an AUTOSAR operating system with Scalability
that is causing the fault and exclude it from further execu-
Class 3 (SC3) that controls a memory protection unit
tion. However, timing protection is only a first step toward
(MPU) with the required ASIL. The watchdog usually han-
the fault tolerant systems that will be needed in the future.
also aims to create an awareness of the challenges of future fault tolerant systems and shows that they can be overcome effectively with AUTOSAR.
In safety-relevant systems of today’s vehicles, the most
with a precise definition of a safe state are still causing
frequent reaction to a fault is to deactivate or reset the
headaches in this context. The second edition of ISO 26262,
faulty function. This is referred to as fail-silent. It is easy to
whose publication is planned for 2017 or 2018, will not
implement this type of solution, and it is effective for
achieve final clarity either. Aside from the requirements set
achieving a safe state and maintaining it. However, E/E
in standards, the following chapters show how existing
systems in the vehicle are increasingly assuming other
safety concepts can be extended to fault tolerant systems
functions that must remain available in case of a fault, e.g.
using AUTOSAR technology.
when a microcontroller fails. This behavior is referred to as
7/18
fail-operational and in the following as fault tolerant. In the
Modular Safety Concept for Fail-Silent Systems
future, the demand for fault tolerant systems will increase
Safety engineers use a modular concept to efficiently tailor
substantially in manufactured automobiles. One example:
the various safety mechanisms to a specific project (Figure 1).
in some of today’s heavy SUVs, it is necessary to keep
Here they make a rough distinction between measures for
steering assist systems active to assure that drivers can
microcontroller integrity, measures for functional monitor-
handle steering safely. While development for fail-silent
ing and comprehensive measures.
systems is now mastered quite well with ISO 26262, issues
Measures for establishing integrity of microcontrollers are
in the design of fault tolerant systems are still difficult to
selected according to the highest Automotive Safety Integ-
resolve with ISO 26262. In particular, attempts to come up
rity Level (ASIL) of the software that is used. They are inde-
Figure 1: A modular concept enables efficient tailoring of safety mechanisms to a specific project.
7/19
Is This What the Future Will Look Like?
highest failure rates in an ECU. Therefore, proper execution
useful for simplifying the application development process
of a function cannot be assured for even a very short time
for the following reasons. >>Re-use: The AUTOSAR components presented above
period. To make this two-channel system fault tolerant, each chan-
that are used to achieve a modular safety concept can
nel must detect all individual errors for itself and switch itself to passive [5]. Without this requirement, both channels
also be re-used by the developer for error detection. >>Use of existing mechanisms: There are two philosophies
are needed for safe operation of the function. However, in
when it comes to implementing the software of redun-
this case the failure rate would double and not be halved as
dant channels: diversity or homogeneity. The diversity
desired. Of course, this system architecture requires a
philosophy uses different software on the two channels.
redundant energy supply for the two channels, just as it
With the same types of channels and microcontrollers, it
requires a redundant communications path to relevant
is possible to use the same software that is simply
partners. The IEC 61508 standard identifies such a system
parameterized differently for each channel. This is done
as a 1-out-of-2 with diagnostics (1oo2D).
with the Post-Build Selectable Mechanism of AUTOSAR, which is normally used to develop ECU variants. The use
Figure 2: AUTOSAR timing protection offers early detection of a violation of the allowed time budget for tasks and interrupts.
of the same types of channels requires examining errors
Systems
with the same cause [7].
In principle, introducing redundancies into the hardware also increases complexity in the application. This creates
To enable a quick switchover of control to the other channel
new challenges in the area of control engineering, such as
in case of a fault, sensor and actuator values as well as
how to achieve controller stability and control actuators
status information on the channel are exchanged between
Fault Tolerant System Architectures
This industry also benefits from lower severity of the con-
when redundant controllers are active at the same time. It
the channels (Figure 3). The mechanisms of AUTOSAR
Fault tolerant system architectures have been used for
sequences of failure in risk assessments.
is also necessary to reassess data consistency in networks
make it possible to implement just one configuration of the
many years now in the aerospace industry. For the safe-
A feasible system architecture (Figure 3) always consists of
(“Byzantine Generals problem” [6]). From a system archi-
basic software. The developer can either implement chan-
ty-critical flight control systems, three or four ECUs are
at least two channels. In this example, one channel com-
tecture perspective, this complexity could be limited by a
nel switching application-specifically as a software compo-
redundantly combined to form a complex system. This re-
prises a sensor, a logic unit and an actuator [4]. It is obvious
hot-standby mode, for instance. In this case, only one of the
nent (SWC) in hot‑standby mode or exploit the flexible
dundancy in the hardware is of course extremely cost-in-
that when the microcontroller of one channel fails, the
two channels controls the actuators at any given time. If an
configuration options of the AUTOSAR manager compo-
tensive. Therefore, new approaches must be sought for
associated software and its functionality fail as well. Due
error occurs on this channel, the other channel immediately
nents Basic Software Mode Manager (BSWM) and ECU
using fault tolerant systems in the automotive industry.
to their complexity, microcontrollers frequently have the
assumes control. The AUTOSAR basic software (Figure 4) is
State Manager (ECUM). Today, application-specific soft-
Figure 3: Example of a fault tolerant system architecture achieved by redundant design.
7/20
Software Architecture with AUTOSAR for Fault Tolerant
Figure 4: MICROSAR software rchitecture for fault tolerant a systems based on AUTOSAR
7/21
ware is implemented to exchange the error status between
Links:
the channels. In the future, however, it is conceivable to
Website Vector: www.vector.com
specify standardized basic software components for ex-
Product Information MICROSAR: www.vector.com/microsar
actly this purpose. Tool Support To overcome the added degree of complexity in the future, effective and comprehensive tool support needs to begin in an early development phase. This frees up resources for focusing on application development and relieves engineers of tedious and error-prone work such as manual consistency checking of redundant signals in the system model. Outlook Today, on-board AUTOSAR capabilities already permit efficient implementation of safety-related projects. If increased fault tolerance of E/E systems is required, new system architectures will be needed that can handle the failure of the microcontroller as well. This presents new challenges for the application and the basic software. Nonetheless, the complexity of these types of systems can be mastered using AUTOSAR methodology. Here, AUTOSAR basic software offers an excellent starting point due to its configurability. The associated tool chain simplifies management of the necessary redundancy. In the future, assistance will be further improved by the basic software and its tools. A first step, however, is to realize that fault tolerant systems also require new approaches in the system architecture. Translation of a German publication in Elektronik automotive, 11/2015 Image rights:: Lead figure: Fotolia #76500668, Originator: Jakub Krechowicz, with modifications by Vector Informatik GmbH Figures 1 - 4: Vector References: [1] Definition of the fault tolerant time interval (FTTI) in ISO 26262-1, 1.45 [2] ISO 26262-5:9 Evaluation of safety goal violations due to random hardware failures [3] ISO 26262-10:4.3 Relationship between faults, errors and failures [4] Definition of a system in ISO 26262-1, 1.129 [5] ISO 26262 Single-point fault metric (SPFM) for ASIL D [6] The Byzantine Generals Problem, L. Lamport et al, ACM Transactions on Programming Languages and Systems, 1982 [7] Definition of a Common Cause Failure in ISO 26262-1, 1.14
7/22
Jonas Wolf (Dipl. Ing.), Vector has a degree in Aerospace Engineering from the University of Stuttgart. He has been working at Vector since 2012; currently he works in the role of Senior Product Management Engineer for Functional Safety and Cyber Security.
CAN FD
Secure communication for CAN FD Encrypted data transmission is not yet the norm in vehicle networks. Vector has conceived an implementation for secure communication over CAN. Protection goals were authentication and preventing replay attacks.
Author
Armin Happel Principal Software Development Engineer Vector Informatik GmbH Ingersheimer Str. 24 DE-70499 Stuttgart Tel.: +49-711-80670-0 Fax: +49-711-80670-111 Link www.vector.com
n today’s vehicle networks, data transmission is for the most part performed without any special security measures. Because of this, it is possible to read out the data transmitted in raw format or to even play it into the bus system in modified form if you have direct access to the vehicle bus. Encrypted data transmission would not only ensure that this information could only be evaluated by authorized recipients. At the very least, it would also make it much more difficult to intercept or alter the messages. Media reports about vehicle manipulation [1], [2] raise the question of whether data in the vehicle network can actually be influenced by manipulation. Can a manipulated device or internally implanted device with a remote
I
control function influence vehicle behavior? And what countermeasures can be taken to prevent such manipulations? Today’s vehicles are highly complex systems, which consist of networked sensors and actuators and continually transmit
important data over bus systems. In the vast majority of cases, the information being transmitted is in raw data format. A plausibility check, if such a check is even possible, has limited effectiveness. The receiver is unable to verify whether the data was
Figure 1: Message transmission and timing of encrypted communication
actually supplied by the desired sender or whether it was fed in by an outside electronic control unit, i.e. whether it is authentic data. The data is freely accessible as well, so an analysis of the bus information can be used to determine signal contents. The transmission is neither confidential nor authenticated. This was the problem that engineers at Vector were confronted with. Their task was to come up with an implementation for secure communication over a CAN network which can be used flexibly and can also be integrated with Autosar-3.x basic software. Protection goals were authentication and preventing replay attacks. It was also desirable to implement communication that cannot be monitored For the encryption method, the specialists chose the AES algorithm [3]. From today’s perspective, this method is considered cryptographically secure. It involves symmetrical block encryption with a block length of 128 bits. It generates 16 bytes or a multiple of 16, which the sender transmits to the receiver. An additional advantage is that some microcontrollers already have very fast hardware-based implementations of this algorithm. Since a CAN message can transmit a maximum of 8 data bytes per frame, a decision was made to utilize the ISO transport protocol (TP) that was already included in the communication stack for the transfer. To simplify the configuration and reduce protocol overhead, a unidirectional communication with a fixed 1:1 relation between sender and receiver was chosen. Symmetrical encryption requires that both the sender and receiver have the same key. The software modules that are used permit dynamic allocation of the keys at runtime, so that the user or OEM can freely
Figure 2: ID keys of multiple receivers in the use of CAN FD choose them. A higher-level method such as a (asymmetrical) key exchange method might be implemented, or a static allocation might be made such as in end-of-line programming. Whenever an ECU is replaced and a vehicle specific key is used, the new ECU must be set up by an authorization method, which keeps the key confidential under all circumstances.
Preventing replay attacks In this configuration, an encrypted transmission of messages is now possible, where the information is, however, still purely static, i.e. a unique key text can be assigned to the plain text signals. This means that replay attacks, i.e. recording excerpts of a desired communication and replaying it into the system at a later time, can still be made. That is because the receiver cannot check whether the message actually originates from the sender at this point in time. To make checking possible, at the start of communication the receiver generates a random value – which is referred to as the ID key in the following – and it communicates this to the sender. The sender increments the value with each transmission and appends it to the transmit message. When the message arrives, the receiver checks whether the ID key matches the expected value. If it does, it processes the message; otherwise it rejects it. To tolerate possible message
losses, the receiver will also accept a slightly higher value. This means that the counter in the transmit message continually alters the encrypted data even if the signal contents remain the same (Figure 1). Depending on the word width of the ID key and the frequency with which the message is sent, overruns of the counter value might be expected in the message, which would lead to repeated transmission of the encrypted message. To avoid this, the ID key is only valid for a certain time period. When this period expires, the receiver must generate a new value and communicate it to the sender. Immediately after receiving a new ID key, the sender transmits the encrypted message. This means that the receiver is also able to initiate repetition of a message, such as if the received ID key does not agree with the internal key, and this reduces latency times. Although the sending node receives and considers new ID key messages for a time T(offset), to avoid an overload of the bus system such messages do not immediately lead to resending of the encrypted message. To make the protocol more robust, the receiving side uses the timer T(Resent) to monitor the response of the sender with the new counter value. If it does not get an acknowledgment message from the sender, the receiver generates a new ID key and resends it. This makes it possible to detect even a brief failure of the sending
ECU and shortens the time for resending. It also avoids storage of the ID key in nonvolatile memory.
Data transmission without segmentation There is a significant disadvantage associated with segmented data transmission in CAN over the ISO15765 transport protocol. Transmission time is increased, and this method is restricted to a fixed 1:1 relationship, because segmented data transmission over ISO-15765 is very difficult to implement with multiple nodes. CAN FD on the other hand enables simultaneous transmission of the entire encrypted message to multiple receivers [4]. Each receiver needs the same symmetrical key to decrypt the encrypted message. Two variants of the ID key for authentication come into consideration: either all receivers agree on a commonly agreed value, or all receivers independently generate and send their ID key to the sender. The sender manages all counters and appends them to the data message. The positions of the counter values within the encrypted message must be uniquely assigned to the receivers. Figure 2 shows data transmission for multiple receivers. First, the receivers transmit their randomly generated start values to the sender. The sender then increments all ID keys for each send cycle and insert them into the encrypted message at the predefined positions. The relevant
CAN Newsletter 4/2014 8/0
8/1
CAN FD
Figure 3: Software components for encrypted transmission Literature [1] http://www.chip.de/news/CANHacking-Tool-Autos-hacken-fuer20-Dollar_67066892.html [only German] [2] http://www.can-newsletter. org/engineering/engineeringmiscellaneous/140822_list-ofpotentially-vulnerable-cars_ blackhat/ [3] Advanced Encryption Standard (AES), FIPS PUB 197 [4] CAN with Flexible Data Rate – Specification Version 1.0, Robert Bosch, GmbH; April, 2012 http:// www.bosch-semiconductors.de/ en/ubk_semiconductors/safe/ip_ modules/can_fd/can.html
receiver then checks its ID key and accepts the data or rejects it (Figure 2). However, as the number of receivers increases, this reduces the message space that remains for useful data. The number of useful data bytes is also highly dependent on the selected word width of the ID key. The communication timing illustrated in Figure 1 was applied. It only required a modification for the sender in receiving the ID key. Instead of immediately transmitting the encrypted message, the sender waits for a configurable time T(IdKeyReply) to allow time for any other ID key messages from other receivers. The special case T(IdKeyReply)=0 covers the original method. Vector implemented the protocol for CAN FD in a CANoe environment. The specialists subjected the protocol to extensive tests using this software tool for development, simulation, and testing of ECUs and networks. Along with the required robustness against replay attacks, another focus was to study message losses, failure, and re-entry of sender and receiver as well as timing errors and burst attacks. In all of these cases, the encryption
system provided a stable transmission.
Summary and Outlook In CAN FD, in particular, it took relatively little effort to implement robust transmission of encrypted data with multiple nodes, and this method can also fit into an existing Autosar environment. One disadvantage is the serialization and deserialization of the data on the application level (Figure 3), which means that modeling properties of the RTE cannot be used any longer for individual signals. The classic points of attack on such systems must still be kept in mind. They include, for example, weak random number generators for the ID keys (at startup) or spying the symmetrical keys. In the security technology world, the AES-128 algorithm is considered secure for the near future, and its implementations are mature or will even be supported by hardware accelerators. The method presented here makes attacks on the CAN (FD) communication much more difficult, and manipulation is hardly possible without “insider knowledge”. It has already been in production use for several years, and it also
has led to favorable classification of the relevant vehicle for insurance premiums. In this case, security not only protects data; it even offers a direct cost advantage to the end user. In the near future, remote connections such as Car2x communication, WLAN, Bluetooth and Internet will continue to grow and will necessitate much more stringent requirements for IT security. These access modes must be made secure against attacks and must not permit any remote manipulation. This is especially true of information to driver assistance systems, which rely on reliable messages from other traffic participants and/or the infrastructure.
Reliable Protection for Your ECU’s and Networks
Automotive Cyber Security Solutions from Vector
In developing security ECU’s, you benefit from a comprehensive Vector solution consisting of software tools, embedded components and services: > Homogeneous solution for testing security-protec-
> Flash bootloader for secure booting and updating of
ted ECU’s and networks > Highly automated testing of security mechanisms
ECU software > Systematic security engineering and creation and
by using fuzzy testing > Efficient and configurable AUTOSAR basic software for implementing security requirements
validation of security concepts More information: www.vector.com/security
Develop your security projects reliably and efficiently with solutions from Vector.
Webinar series with valuable know-how and free tips from experts. Register now at: www.vector.com/sec-webinars
CAN Newsletter 4/2014 8/2
Vector Informatik GmbH | Germany · Austria · Brazil · China · France · India · Italy · Japan · Korea · Sweden · UK · USA | www.vector.com
Integrated Development of Safety and Security Requirements Today, the systematic development of safety requirements is essential in developing embedded systems. Due to the growing number of functions and interfaces to backend and cloud services, the consideration of safety in conjunction
System: e.g. lane departure warning assistant
Function: Corrective steering intervention
Asset: Protect assistance function from manipulation
Hazard analysis
Threat analysis
Requirements for safety
Requirements for security
with security is becoming increasingly more important. However, a universal approach is lacking in this field. This article presents a method for integrated, semi-formal development of safety and security requirements. The advantages of this requirements engineering methodology for safety/security are illustrated by the example of an ADAS (Advanced Driver Assistance System), and the potential of tool support is demonstrated.
8/4
Requirements for Safety and Security
constraints. Related monitoring actions assure proper exe-
Cloud services, such as emergency systems, which are essen-
cution. This is known as “functional safety”. The absence of
tial for survival are being paralyzed. Hackers are penetrat-
danger also implies trust. I can trust that a message from
ing into train control systems and causing malfunctions.
a sender really originates from that sender. Or I might want
Industrial systems are being sabotaged by trojans. Im-
to transmit a message and be certain that no one can alter
planted medical devices are being manipulated via the
it. This specific aspect of safety represents the subject area
diagnostic interface, causing them to fail in their tasks.
of “security”. It relates to the integrity, authenticity and
Who has not seen such headlines? The sabotage of critical
trustworthiness of information, which is why it is referred
we want to present an integrated, systematic approach in
operating scenarios are defined. In threat and risk analysis,
infrastructure is not only the goal of terrorists, but unfortu-
to as information security.
the framework of requirements engineering. First, excerpts
hazardous events are derived from the basic functions and
nately increasingly the doing of misguided professionals as
The fundamental meaning of quality in relation to a system
of the methodology for safety requirements are described
potential malfunctions. This involves quantifying a hazard-
well. The one wants to demonstrate the helplessness of our
is that the system provides the functions expected of it [1].
in section “Developing and Verifying Safety Requirements”.
ous event’s risk level – also known as the Automotive Safety
society, while the other is seeking personal power. Increas-
When safety and security are interlinked, this classic defini-
We intentionally restrict this to the creation of functional
Integrity Level (ASIL) – under consideration of the relevant
ing numbers of embedded systems are becoming critical to
tion is extended to include the meaning that the system does
safety requirements, because early phases have a large
operating scenarios. For each relevant hazardous event,
safety. Compromised software can lead to the failure of
not provide any other functions that are not expected of it
effect on the rest of the process. They form the foundation
safety requirements known as safety goals are identified,
critical functions. An insulin pump, like the type implanted
– because of failure, human error, equipment malfunction
for an integrative approach to security requirements that
which are still relatively roughly defined. In the design steps
in many people, can be manipulated by an informed hacker
or malicious attack. In this article, we will use the concepts
is presented in section “Developing and Verifying Security”.
that follow, the safety goals are broken down into func-
to deliver the incorrect dosage – with potentially lethal con-
of “safety” and “security” to better distinguish the seman-
Section “Case Study: ADAS System” illustrates an integrated
tional safety requirements and allocated to elements of
sequences. It is high time to not only derive safety require-
tics and thereby the different methodological approaches.
approach based on the example of an ADAS (Advanced
the system design that are responsible for implementing
ments from software errors and random malfunctions, but
In the future, functional safety will no longer be sufficient
Driver Assistance System). The potential for tool support is
the requirements. Together they make up the functional
to also focus specifically on attacks related to the security
without “information security”. This is reflected in two im-
discussed in section “Potential for Tool Support”.
safety concept. All other process steps for safety, such as
of information.
portant trends: constant growth in the networking of func-
Functional safety and information security are becoming
tions and the development of increasingly more autono-
Developing and Verifying Safety Requirements
the scope of this article. In the next section, we supplement
more intertwined. Functional safety requires reliable and
mously acting diagnostic and assistance systems. Both of
First, the limits of the system under consideration are set,
this methodology with procedures for developing and veri-
secure information, whether it involves vehicles, medical
these trends are generating a growing number of poten-
and its basic functions are described. In addition, relevant
fying security requirements.
equipment or industrial automation. The focus here is on
tially safety-relevant functions. A relatively new trend that
requirements for security and verifiable, systematic and
can be identified is the growing trend toward networking
universal requirements engineering. The goal of integrated
vehicle functions with back-end services by automotive
safety and security development is to limit the risk of
manufacturers or IT cloud services. This networking opens
hazardous situations to an acceptable level by developing
up entirely new services and business models such as
functions that can react as robustly as possible to equip-
retrofitting functions by software update or communica-
ment and human errors as well as external attacks. This
tion between devices, e.g. IT and automation engineering in
article shows how functional safety and information secu-
Industry 4.0. This linking of differing components and their
rity can be successfully implemented in such systems from
networks with open, external networks increases the
the perspective of requirements engineering.
potential for security-related threats.
In German, the word “Sicherheit” has two meanings. “Sicher
In requirements engineering, the dependencies and mutual
heit” means the absence of danger. The use of a product or
interactions between safety and security requirements
function must not endanger the health or well-being of the
must be viewed in a methodically clean and systematic
user or the environment. The producers and hence the
way. The described interrelationships are visualized in
developers of a function must assure that this function is
Figure 1. They must be made manageable by an integrated
available when it is needed.
approach to developing and verifying requirements. Cur-
Equally important is assurance against unnecessary execu-
rently, this is handled rather unsystematically, because in-
tion of functions. Here, a list of measures can contribute
dustrial standards for safety and security are still very
toward preserving the desired functionality under various
much treated in isolation from one another. In this article,
New functions with added value and with manageable risk
Figure 1: Requirements engineering identifies mutual interactions and dependencies of safety and security
quantitative and qualitative safety analysis, are beyond
Potential for attack on
Asset
Attack potential
has a value for
Potential with risk of
Potential for executing
Threat Risk is reduced by
has Owner
Attacker
Malicious action
Security goal
is performed at
Point of attack Figure 2: Interrelationships in threat and risk analysis
8/5
Integrated Development of Safety and Security Requirements
Developing and Verifying Security Requirements
driving lane. If necessary, it makes a steering intervention
departure warning system is the following situation desig-
In the asset definition process, one of the assets defined is
After the basic system functions have been defined, they
to steer it back into the lane. The system has a number of
nated BS1: “Driving on country roads, oncoming traffic,
A1: “The lane departure warning system behaves within its
are used as a foundation for identifying protective assets
sensors for acquiring the surroundings and a number of
speed > 50 km/h.” In the framework of hazard and risk
specification.” Asset owner B1 is the vehicle manufacturer.
and their owners [2]. An example of an asset for vehicle
actuators for performing driving interventions and for
analysis, malfunction FF1 was identified for F1: “Counter-
Attacker AT1 is an experienced hacker. An attacker of this
owners is that their personal privacy cannot be violated by
notifying the driver. The prescribed system structure is
steering is executed, but in the wrong direction.” Hazardous
type typically has the basic abilities needed to perform re-
third parties evaluating their movement profiles. In threat
shown in Figure 4.
situation H1 results from the interplay of F1, FF1 and BS1:
verse engineering of hardware and software and to install
and risk analysis, the assets are used as a basis for identi-
This example illustrates similarities and differences in the
“A collision with oncoming traffic occurs.” To assess the rel-
its own malware via remote interfaces which then commu-
fying attackers who would have the potential to execute a
development of safety and security requirements in early
evance of H1, the analysis utilizes the criteria of probability
nicates with the rest of the system. AT1 can perform the
malicious action at an attack point in the system and
phases.
of occurrence (O), degree of severity (S) and controllability
malicious action FA1: “Suppress messages to actuators
therefore represent a threat to the asset. The risk is a func-
Due to its direct effects on vehicle dynamics, the system
(C). Safety goal SG1 is defined to avoid H1: “Avoid implau-
when departing from the driving lane by manipulating
tion of the attack potential and the severity of the threat.
must set requirements for functional safety, e.g. avoid
sible steering intervention of the lane departure warning
functional software.” The identified attack point AP1 is
The owners of the assets want to reduce the risk of threats
unintended steering or braking maneuvers. Networking of
system.”
to an acceptable level by implementing suitable security
very different information sources in the sensor fusion pro-
goals. These interrelationships are shown in Figure 2.
cess – such as radar and camera systems and various ECUs
Identifying Assets and Deriving Security Goals
is assessed based on multi-dimensional criteria. These cri-
In subsequent design steps, the security goals are broken
in the vehicle – requires careful verification of measures
In the framework of system definition, the assets worth
teria include the attacker’s knowledge of the system, the
down into functional security requirements and allocated
against external attacks. These requirements mutually in-
protecting are first identified, and security goals are de-
attacker’s technical resources, and the time needed to exe-
to elements of the system design that are responsible for
fluence each other in their methodical implementation and
rived in the framework of threat and risk analysis.
cute an attack. The attack on the asset leads to threat T1:
implementing the requirements. Together they form the
must therefore be developed together. We want to demon-
functional security concept. Analogous to the approach
strate this based on the described methodology.
manipulation of the ADAS system software by an unauthorized software update. The attack potential of the attacker
taken for safety, all further security process steps that take place are beyond the scope of this article. Figure 3
Identifying Basic Functions and Deriving Safety Goals
shows, in simplified form, security activities in the context
In the context of system definition, the basic functions are
of their relationship to the overall process and to safety
first identified, and safety goals are derived in the frame-
activities.
Attack: Delay or Remove Warning Messages
Advanced Driver Assistance System Sensor Fusion
Night Vision Front Camera
work of hazard and risk analysis.
Central Processor
Steering Column
In the lane departure warning example, one of the funcCase Study: ADAS System
tions identified is the following function F1: “The lane de-
A sub-system of an ADAS (Advanced Driver Assistance
parture warning assistant automatically initiates a steer-
System) for an automobile is used as an example in the fol-
ing intervention after detecting that the vehicle is leaving
lowing. This sub-system is a lane departure warning assis-
the lane and after a warning time has passed.” One of the
tant that warns the driver before the vehicle leaves the
operating situations identified as relevant to the lane
Front Camera
Electronic Brake
Mid Range Front Radar
Driver Display
Watchdog
Long-Range Front Radar
RAM RAM
Item definition
ROM
Assets and attack potentials
Functions and scenarios
Threat and risk analysis
Hazard and risk analysis
Security goals
Safety goals
Security architecture
ROM
Functional safety concept
Technical security concept
Technical safety concept
Implementation of security mechanisms
Implementation of safety mechanisms
Safety case
Security case
Validate safety assumptions
Validate security assumptions
Testing of safety mechanisms Testing of safety mechanisms
Safety analyses
REVERSE CAMERA
VIDEO CAMERA
Testing of security mechanisms & penetration tests
Testing of security mechanisms & penetration tests
Security analyses Safety activity
Security-conformant implementation of nominal functions
8/6
NIGHT VISION CAMERA
Security activity
Figure 3: Shared view of safety and security requirements
LONG-RANGE RADAR
MID-RANGE RADAR FRONT
ULTRASOUND
MID-RANGE RADAR BACK
Figure 4: Rough system structure of ADAS (sub-system: lane departure warning assistant)
8/7
Integrated Development of Safety and Security Requirements
“The vehicle behaves like a system that is shut-off without
For instance, ensuring the consistency of safety and security
are able to support requirements development and system
the driver being aware of it. This could lead to accidents for
goals and the requirements derived from them over the en-
design in an integrated way. This is enabled by graphic visua
which the automotive manufacturer is blamed.” The sever-
tire life cycle can only be accomplished with great effort.
lization of the allocation as shown in Figure 5. Such types of
ity of this threat can now be assessed based on various se-
One step toward an integrated safety and security concept
visual representation make it easy to recognize contradic-
curity relevant criteria. They include the threat’s potential
and an advantageous refinement of requirements is allocat-
tions quickly.
for violating safety goals as well as the threat’s potential
ing safety and security goals to the preliminary architecture.
In Figure 2, we show the interrelationships between security
for operative and financial damages to asset owner B1. To
The advantage here is that it is possible to track require-
goals, malicious actions and assets. Such interrelationships
counteract the threat, security goal SCG1 is derived: “Pro-
ments to the concept level very early on. This also permits
are easy to formalize in integrated tools in order to per-
tective SW and HW security mechanisms must assure that
early detection and resolution of potential contradictions
form pattern-based consistency checks and recognize gaps
software and configuration parameters for the lane depar-
and conflicts between safety and security requirements in
and insufficiencies in requirements. If this occurs while re-
ture warning system cannot be falsified or delayed without
system elements. To achieve this, it is advantageous if tools
quirements are being developed, this offers the potential
this being recognized.”
Christof Ebert is CEO of Vector Consulting Services GmbH and a professor at the University of Stuttgart
Eduard Metzker is Solution Manager for Cyber Security at Vector Informatik GmbH
for reducing the effort required for manual reviews.
Table 1 provides an overview of the similarities and differences in determining safety and security requirements. After deriving the safety and security goals, further refinement to the functional and technical requirements level is possible. In each phase, it is advisable to mirror the requirements by allocating them to the (preliminary) functional and/or technical architecture. Potential for Tool Support In classic tool chains such as those used in system develop-
Safety
Security
Starting point
System and top-level functions
System and assets to be protected
Determining top requirements level
Risk-based derivation of safety goals under consideration of malfunctions of system functions
Risk-based derivation of security goals under consideration of potential attacks on assets
Risk assessment
The risk level of a hazardous event is assessed by evaluating its probability of occurrence, severity and user’s ability to control the hazardous event.
The risk level of a threat is assessed based on the attacker’s attack potential and the severity of the threat. The severity is subdivided into the assessment dimensions of func tional safety, economic costs and personal privacy.
ment today, the processes described in sections “Developing and Verifying Safety Requirements” and “Developing and Verifying Security” are very fragmented. Requirements development, functional design and safety and security analyses are performed with various tools, wherein the interfaces often do not permit loss-free exchange of information.
Summary and Outlook Requirements engineering for safety-critical systems must include the systematic development and evaluation of requirements for functional safety and information security simultaneously. The previously established separation of these concepts, treating them as two disciplines – each with its own standards and approaches – is no longer acceptable,
Table 1: Comparison of approaches for determining safety and security requirements
because this approach overlooks dependencies and mutual interactions. A separated approach is also inefficient, because many of the functions need to be acquired multiple times. Methodological processes for assuring consistency, traceability, verification, modeling and test orientation should be applied together. A semi-formal specification of safety and security requirements, together with suitable tool support, makes a contribution toward managing complexity and effort. Translation of a German article for ObjektSpektrum on the special topic of Requirements Engineering
Lane Position / -;R+1 (Sense)
Keep Vehicle in Lane / -;R+1 (Logical Function) Alarm:LKAAlarm LanePosition:LanePosition
Lane Position:LanePosition {-/LanePositio…
Sound Alarm / -;R+1 (Actuation) Alarm:LKAAlarm {-/AlarmCode/-} Warn Driver when leaving lane
Literature [1] Ebert, C.: Systematisches Requirements Engineering (“Systematic Requirements Engineering”). Dpunkt-Verlag
Indicators / -;R+1 (Sense) Indicator Position:IndicatorStatus {-/IndicatorStat…
Indicators:IndicatorStatus LKAWarning:LKAWarning
{-/WarningCod…
Vehicle Speed / -;R+1 (Sense)
Display Warning / -;R+1 (Actuation) DisplayText:LKAWarning
(“Dpunkt Publishers”), Heidelberg, Germany, 5th complete-
Warn Driver when leaving lane
Ebert, C.: Systematic Requirements Engineering (Chinese). Chinese Translation, ISBN: 978-7-111-43986-8, Huazhan
VehicleSpeed:Speed
Current Speed:Speed {-/VehicleSpee…
CounterSteering:CounterSteering
ASIL Colours Functions
Brake Pedal / -;R+1 (Sense)
ASIL undefined / -;- (Sense) BrakePedal:BreakPedalStatus
BC:BreakPedalStatus {-/BrakeComm…
QM / -;- (Logical Function) LKAStatus:LKAStatus
Angular Speed of Steering / -;R…
AngularSpeedOfSteering_SteeringW…
SWP:SteeringWheelStatus
ly revised edition, 2014.
Allocated Requirements unassigned
http://www.hzbook.com/Books/7318.html
QM
[2] CCRA, “ISO/IEC 15408: Common Criteria for Informa-
ASIL A
tion Technology Security Evaluation,” 2012.
ASIL B ASIL A / -;- (Logical Function)
Publishing Group, Shanghai, 2013.
ASIL C ASIL D
{-/SteeringWhe… ASIL B / -;- (Actuation) Inhibit unintentional steering action Assure activation above 30 km/h Assure activation after warning time Assure correct direction of counter steering
ASIL C / -;- (Logical Function)
ASIL D / -;- (Logical Function)
Figure 5: Allocating safety goals to system elements
8/8
8/9
Cyber Security – Challenges and Practical Guidance
More connectivity bears also the risk for attacks to the car.
that are specific to automotive security. In section 3 we
Success Factors for Security Engineering
From painful experiences in standard IT and communica-
present solutions that proved valuable in several automo-
tion domains it is known that distributed systems and
tive security engineering projects. Based on our experiences
communication are subject to unauthorized manipulations,
with these solutions we have identified several activities
such as eavesdropping, manipulation of message contents,
that leverage the successful application of security engi-
use of resources, etc. The data processing and communica-
neering – these are outlined in section 4. This article is con-
tion activities in automobiles are no exception – in fact, the
tinuously updated and in its latest version available through
properties of vehicles and their E/E architecture can make
Vector Consulting Services1.
Cyber security is of a growing concern across industries. It is today not anymore nice to have, because systems are interconnected, and in one way or the other open for external penetration. Even worse security directly impacts functionality, user experience and safety, and thus has become subject to product liability. For instance, functional safety is not feasible without a concise approach to cover cyber security. Based on the specific challenges of automotive security, OEMs and suppliers have to realize an effective protection against manipulations of electronic systems. Key points in the development of protected systems are the proper identification of security requirements, the systematic realization of security functions, and a security validation to demonstrate that security requirements have been met. Based on our experiences inside Vector and with client projects around the world, we will show typical challenges and highlight suitable security guidance. We will show with concrete examples how these practices improve developing secure systems and how these activities can be performed efficiently.
unauthorized manipulations even easier than in many other systems.
2. Challenges of Automotive Security
Figure 1 shows car connectivity on-board in the distributed
Security directly impacts safety, and thus is crucial to pro-
systems as well as from the car to its environment. Each
tect the driver and its environment. Automotive OEMs and
connection has a potential risk for an attack, regardless if
suppliers today are well aware that insufficient security en-
it is wireless or wired. Just the threat is different. The ac-
gineering has direct and immediate effects on product lia-
cess through a connector shows limited risks, because it is
bility. Figure 2 shows how security attacks impact safety by
only possible for single cars, whereas a far field connection
creating hazards, either by intended malfunctions like in
1. Introduction
Information security increasingly impacts today and future
is much more dangerous because it can be accessed from
our introductory story, or by unintended malfunctions for
Night drive on the highway. The communication display
electronic systems. A growing number of automotive com-
anywhere in the world. But also near field connections play
instance due to DOS attacks. Security engineering is not
flickers and suddenly annoying whistling sounds abruptly
fort, reliability, and safety functions are realized by soft-
an important role, such as tire pressure monitoring system,
rocket science and thus with sufficient competence and
from of the speakers. The driver is surprised, looks to the
ware applications that are executed by distributed elec-
Bluetooth and wireless LAN which is accessible from pass-
willingness can be implemented – and must be maintained
display, tries to calm down the whistling tone – and causes
tronic control units (ECUs). Besides the further develop-
ing by or parked cars.
throughout the lifecycle of any vehicle.
an accident. Reality or fiction? With increasing complexity and
ment of innovative sensors like radar and camera systems
Anything that can be exploited by an attacker will be if the
Automotive security has to deal both with coincidental
networking, the use of standard components and open
and highly complex infotainment and assistance systems,
gain is significant enough. Therefore, it is required to ensure
events (e.g. defective ECUs becoming babbling idiots) and,
interfaces, the various electronic systems, especially in the in-
connected cars are pushing tomorrow‘s innovation. Inter-
that automotive systems can either not be exploited or the
especially, with events that are intentionally caused by per-
fotainment, increasingly vulnerable and must be protected.
net connections will not only provide the need for informa-
gain of manipulations is reduced below profitability. Secu-
Functional safety today needs information security. What
tion to the passenger. Functions like eCall or communica-
rity and reliability will be essential for the acceptance and
sons with certain motivations, such as: >>Activation of features that can be enabled by software
exactly is information security (IS)? Basically IS is a system
tion between cars or car to infrastructure (Car2x) will evolve
success of modern automotive IT and electronic systems. In
property and relates closely to availability, functional safe-
traffic. This includes improved traffic flow controlled by in-
the standard IT and telecom domains, a plethora of meth-
settings, e.g. “chip tuning”. >>Car and vehicle parts theft.
ty, robustness and performance. Quality in a system will
telligent traffic lights, OEM backend systems to provide
ods, techniques, best practices, and patterns have been
>>Component plagiarism.
generally mean that the system does everything that is ex-
latest mapping data, warnings from roadside stations or
created in order to develop IT systems that are less vulner-
>>Manipulation of remote key systems, immobilizer
pected of him. IS goes beyond this classical definition in the
brake indication of adjacent cars. Enhanced driver assis-
able to unauthorized manipulations. This discipline of secu-
sense that the system itself in a malicious attack does
tant systems and automated driving are gradually appear-
rity-aware development is referred to as security engineer-
systems. >>Manipulation of telematics systems, e.g. to obtain
nothing which is not expected.
ing on our streets.
ing – it deals with processes, methods, and tools for designing, implementing, and testing secure IT systems. In this paper, we depict how security engineering can be successfully incorporated into automotive systems devel-
Connected Cars ‒ Tomorrow Car2x
Distributed onboard communication across ECUs and sensor fusion
eCa 112 ll
ISO 15118 – Vehicle to grid communication
Roadside ITS Station
802 WL .11p AN
NFC Off-Board Tester
Tire pressure monitoring via near field communication
might provoke further motivations for attacks. 1 Contact us on the entire Vector security portfolio: mailto:
[email protected] or www.vector.com/security
Security Directly Impacts Safety
OEM Backbone
Attack
BlackBox (data collector) for insurance, etc.
8/10
opment. Section 2 therefore summarizes the challenges
navigation systems’ maps. >>Furthermore, new features such as car-to-X services
Passengers internet (Google, E-Mail, ..) Car Information (weather, traffic, map, ..)
Figure 1: Modern car connectivity
Hazard
People and environment attack the system thus creating malfunctions.
People and environment can be harmed by malfunctions.
Security: Prevention of unintended behaviors
Safety: Prevention of harm and injuries
Figure 2: Security Directly Impacts Safety
8/11
Cyber Security – Challenges and Practical Guidance
the requirements on the different components. Multiple
result from an attack. Therefore, the security requirements
implementing countermeasures to the identified threats.
vides several access points for attackers to mount an at-
suppliers develop and manufacture the components. How-
have to be identified, before the development of security
An example for a security-related user story could be: All
tack. It is often possible to physically access the E/E buses
ever, security itself is an emerging property of the entire
measures can take place. Without a thorough security
ECU applications have to be authenticated before use.
that provide for data transfer inside of the vehicle. Many of
system that cannot be overcome by one party alone.
requirements elicitation, critical assets may be left insuffi-
The approach has proven valuable, because security re-
the relevant bus technologies are inherently insecure. Due
ciently protected or too much effort may be invested in
quirements had to be identified in a very short time frame.
to the growing connectivity of modern vehicles (e.g. car-to-X
3. Successful Solutions for Automotive Security
protecting uncritical features. Like any other requirements,
The approach is lightweight, its results are concise, and it is
concepts, Internet connection), external communication
Engineering
security requirements have to be complete, consistent,
well suited for application during workshops with domain
interfaces such as LTE, Bluetooth, WLAN, and USB that
Automotive E/E systems comprise many different func-
comprehensive, and testable. Unlike most other require-
experts, i.e. automotive engineers. However, it is less suited
allow for access to the E/E components might be used for
tions, ECUs, and communication systems, which can be at-
ments, they are concerned with what a system should not
for complex systems because it lacks a systematic proce-
manipulation. Additionally, the exposure of vehicles enables
tacked with different methods. The impact of an attack
do under any circumstances, including intentional manipu-
dure – it strongly relies on the people and their knowledge
attackers to physically access the ECU hardware, which
depends on the concrete function that is attacked. To re-
lations. Therefore, specific methods are required to identify
both on the system and on security. Other approaches
makes possible a wide range of manipulations, including
duce the complexity that is created by the huge number of
security requirements.
overcome these limitations, however at the cost of in-
passive (side-channel) attacks and active (non-) invasive
targets, attack methods, and impacts, we suggest taking
In a recent client project, we had to identify and prioritize
creased effort. An overview on security requirements anal-
attacks to compromise existing protection mechanisms.
three different perspectives on automotive security, which
security requirements for an automotive E/E component.
ysis methods is given in [2].
Additional to the vulnerabilities of the automotive system,
each address a manageable, coherent set of questions. These
Based on the size and complexity of the component devel-
It has to be noted for any approach that is used: To identify
there is also a severe disproportion between the resources
perspectives and the corresponding questions are [2]: >>The product and its architecture: What can be compro-
opment project and the given capacity for security engi-
threats that emerge from technical features, an intimate
neering, we selected an agile approach [1] that was con-
knowledge of that technology as well as an attacker mind-
a strong disadvantage on software-based automotive pro-
mised? What risks arise from potential manipulations?
ducted in form of several workshops. The client’s engineers
set are required.
tection mechanisms [2,3]. To compromise these mecha-
What has to be protected? >>Engineering for security: Which activities have to be per
provided expertise on the component’s functions and their
nisms, an attacker has an arbitrary amount of time, where-
implementation. We moderated the workshop and provid-
3.2. Engineering for Security
as the time available for the execution of the protection
formed to protect the vehicle? Which technical solutions
ed expertise in security requirements analysis as well as
While security requirements are concerned with what has
mechanisms is short (e.g. for the encryption of a message).
exist for automotive security? How can these solutions
knowledge on the used technologies’ vulnerabilities and
to be protected, security engineering defines how the pro-
The same holds true for computational performance and
be implemented according to the specific constraints?
sensible protection mechanisms.
tection is realized. It affects all activities that are associat-
memory capacity: an attacker can employ one or more high-
How can the security of the system be demonstrated? >>After sales: How are diagnosis, parts exchange, etc.
The key activities of the selected approach consist of the
ed with “normal” engineering, such as system design, soft-
formulation and evaluation of abuser stories and the cre-
ware construction, test and after sales. We regard each of
only comparatively low processing and memory resources.
affected by protection mechanisms? How to cope with
ation of security-related user-stories. Abuser stories are
these activities in the following paragraphs.
Automotive security is a relatively new issue. Hence there
vulnerabilities that are detected not until SOP?
brief, informal descriptions of how an attacker might abuse
The exposure of automobiles and their E/E architecture pro-
of an attacker and the resources of the vehicle, which places
performance computers while automotive ECUs possess
the system. The abuser stories are written on index cards in
Design
These perspectives (see Figure 3) along with techniques
a language understandable by developers. An example for
In an ideal world, the design of a vehicle’s architecture
over, the adaptation of the basic security building blocks
that we successfully employed in client projects are depict-
an abuser story is: A chip-tuning firm flashes unauthorized
would consider security from the beginning on. Unfortu-
(such as cryptographic algorithms) to the automotive envi-
ed in the next sections.
software on the ECU. The index cards were then pasted to
nately, in reality many architectural decisions are deter-
a white board with their respective positions determined by
mined by other factors, e.g. existing architectures of prede-
3.1. The Product and its Architecture
the probability of the abuser story and its impact, which
cessor models, quasi-standard technologies, and cost fac-
To make matters worse, automotive E/E systems are not
The key to effective security is to know which assets have
gives a vivid impression of the risks of the abuser stories
tors. Additionally, security requirements are often not
only complex but typically also developed and produced
to be protected (and which do not). From an automotive
(Figure 4) – we defined the risk as the factor of probability
identified on product level but only on function level, e.g. in
across different organizations. The car manufacturer (OEM)
viewpoint one is interested in what vehicle functions can be
and impact of an event.
the case of security-affine functions, such as remote-key
provides specifications of the system architecture and of
compromised by attackers and in the implications that
Based on the risks, the abuser stories that have to be
functions, immobilizer functions, or tachometer functions.
prevented were selected and security-related user stories
As a result, many automotive E/E architectures are inher-
were developed, which form the security requirements for
ently insecure, what requires adding security as an after-
are not many experts available with expertise in both information security and automotive systems engineering. More-
ronment and the composition of these building blocks to secure protocols are difficult.
Product/ Architecture
Impact
Medium risk Abuser Story 1
Abuser Story 4
Abuser Story 6
Engineering
Abuser Story 2
Abuser Story 5
Abuser Story 3
After Sales
Low risk Figure 3: Perspectives on automotive security
8/12
High risk
Probability
Figure 4: Abuser story risk evaluation
8/13
Cyber Security – Challenges and Practical Guidance
thought. When designing protection mechanisms for specific
to orchestrate common security solutions starting with base
phisticated attacker may perform hardware attacks such
In a client project, we performed reviews on the security
functions, one is regularly faced with the following tasks: >>Ensure the operation of the function according to its
software and even underlying hardware, rather than ad-hoc
as side channel attacks or invasive attacks.
requirements and inspections of the security architecture.
implementations specific to OEMs and components. For in-
Resource efficient implementation is not specific to securi-
The problems we identified in these early phases could be
specification. This requires the protection of the func-
stance, Vector is supplying secure communication protocols
ty, so we will not discuss it here. As we have seen in a recent
eliminated with comparably low costs. In this project we
tion’s implementation against unauthorized change. >>Ensure the right operation of the function according to
within AUTOSAR for secure end-to-end communication [4].
client project, the introduction of a secure coding standard
also created a simulation based on the design of the secure
In a project with an OEM we supported the development of
can reveal and subsequently reduce potential software vul-
communications protocol using a widespread tool for ECU
the current situation. This requires the protection of all
a basic security architecture that defines a security proto-
nerabilities. Such secure coding standards, e.g. for the C
and network design and analysis, which allowed for an ear-
information used as input by the function.
col on system level for security-critical communications as
programming language, ban insecure coding practices and
ly evaluation of the security properties in a complex envi-
well as reference implementations. A single security archi-
undefined behaviors that can lead to exploitable vulnerabil-
ronment without the need for actual hardware (Figure 6).
For both tasks, there are technical solutions available, such
tecture can be tried and tested more intensively than a
ities. As a matter of principle, we suggest the application of
To validate system security (i.e. to check the actual system’s
as cryptographic algorithms that provide integrity or authen-
multitude of isolated functions and should therefore pro-
the MISRA-C guidelines and to use any measure one gets
performance against the system’s security requirements), two
ticity on the basis of conventional and elliptic curve cryp-
vide a higher degree of maturity and security. In the mean-
“for free”, like setting the compiler to the highest warning
approaches have to be considered: First, the functional test of
tography. However, we have to emphasize again that, even
time we have developed and introduced a dedicated secu-
level. The conventions have to be strictly checked and en-
the security mechanisms has to ensure their implementation
if established algorithms can be considered secure, design-
rity protocol on top of the standard component require-
forced, preferably with automatic analysis tools, such as
conforms to requirements and that all of the security require-
ing a protocol that defines the communication, authentica-
ments specifications [4].
LDRA’s TBsecure.
ments have been realized. This does not differ from “normal”
For the protection against hardware attacks, one possible
validation tests. Additionally, we recommend penetration
tion, etc. is considered highly difficult and susceptible to failure, what might compromise its security.
Implementation
solution is to employ tamper-resistant hardware. In spite
tests, which simulate attacks on the system and may be inde-
While the protection of a function’s implementation against
Not only the design of security-critical functionality is chal-
of such measures, we recommend designing the system in a
pendent of the security requirements. While the first approach
unauthorized change usually does not influence other func-
lenging, so is its implementation. First, there is a dispropor-
way that the attack does not scale – i.e. compromised ECUs
can be performed by regular testing staff, the second one re-
tions of the vehicle, the protection of the input information
tion of the resources available to an attacker (long time
do not affect other elements. For secure implementation,
quires specific security expertise: the mindset of an attacker is
by a cryptographic protocol does. Therefore, information
span, high computing performance) and to the ECUs (short
too, the bottom line is that a strong fundamental knowl-
required to design such tests and to interpret the test results.
transmitted via the vehicle’s E/E buses need to be secured.
time span, low performance). Effective cryptographic algo-
edge of the language and the environment is required [4].
Because an attacker might be able to access these buses and
rithms are often resource-intensive and therefore usually
to manipulate the messages, an implementation of a securi-
have to be implemented specifically for the target ECU.
Verification and Validation
To enable efficient after sales activities in spite of con-
ty protocol needs to be integrated into both the sending and
Second, the code has to be robust against manipulations,
Security vulnerabilities can emerge both on conceptual level
straining security mechanisms, several aspects need to be
the receiving ECUs (Figure 5). Vector is very much engaged
such as inputs that result in buffer overflows. Third, a so-
(e.g. insecure communications protocol) and on implemen-
addressed. How can software updates be performed in the
tation level (e.g. susceptibility to timing attacks). Therefore
field with both security against unauthorized manipula-
a strict verification of the security concept is required, from
tions and justifiable logistical effort? Currently Vector is
the security requirements through the design of securi-
heavily engaged into secure communication protocols within
ty-critical functionality (including protection mechanisms)
the AUTOSAR base software to achieve a secure end-to-
to the implementation. For the development of securi-
end communication on evolving protocol stacks. However,
ty-critical software, the same verification mechanisms can
the concrete realization of the related logistical infrastruc-
be used that are recommended as good practices e.g. by
ture needs to be considered.
Automotive SPICE, such as reviews, inspections, and tests
An important aspect of after sales activities is the way
on different levels.
OEMs and suppliers react when a security issue is detected
Network Strategies Gateway
HSM
External communication module
3.3. After Sales
Body Low security zone Medium security zone High security zone
Test Cases
Infotainment
Powertrain
ECU 1 Function implementation Security protocol implementation
Company 2
ADAS
Company 1
Chassis
Dependancy
ECU 2 Function implementation Security protocol implementation
Security Protocol Design Specification
Test Results
Protected message
Figure 5: Security protocols have to be integrated into sending and receiving ECUs
8/14
Simulation/Test
Figure 6: Simulation and test of the security protocol using Vector modelling and test tools
8/15
Cyber Security – Challenges and Practical Guidance
in a fielded vehicle. Such scenarios have to be foreseen be-
not claim that these are the only valid solutions. Depending
>>Align underlying development methods and processes, e.g.,
fore the vehicle’s SOP and procedures that define actions
on e.g. corporate culture, existing experiences, and project
architecture design and evaluation, security design, coding
and Practice
and responsibilities have to be set up. Actions to be planned
size and complexity, other solutions may be preferred.
rules, hardening, robustness and misuse testing, life-cycle
https://vector.com/portal/medien/vector_consulting/
robustness; tool support for combined safety and security
webinar_podcast/Vector_FunctionalSafety_BestPractices_
engineering and consistency across the entire life-cycle
Webinar_EN.mp4
are risk assessment of the issue, elimination of critical soft-
[3] Ebert, C: Functional Safety with ISO 26262 – Principles
ware vulnerabilities, and update of the software in the
5. Summary
field. To achieve an efficient issue handling, a smooth coop-
Security engineering is a challenging task for both OEMs
eration between OEM and suppliers is required.
and suppliers. While automotive security may not yet be in
As a global market leader for many years, Vector supports
Connected Cars.
the customers’ focus today, we should consider the lessons
all necessary automotive security engineering domains, start-
https://www.vector.com/portal/medien/vector_consulting/
4. Levers for Security Engineering
learned in other industries, where security is now a matter
ing with standard software such as AUTOSAR, providing a rich
publications/Happel_Ebert_Security_Connectivity_2015.pdf
Security engineering needs specifically tailored solutions.
of course. In this paper, we depicted several security engi-
portfolio of modelling and test tools such as PREEvision,
There is not one solution which fits to all architectures,
neering approaches that we applied within the automotive
and also having the experiences to support consulting on
products and practical use cases. For instance we are using
industry.
how to build an efficient security and safety engineering in
with many clients a checklist which is adapted to the spe-
We should take benefit from security experience in other
organisations around the world. Figure 7 shows the Vector
cific environment and security risks. The checklist though
critical domains >>Apply cybersecurity principles and methods to harden
security portfolio and its levers to ramp up security.
distributed embedded systems >>Adopt the IT standard “Common Criteria” for automotive
ing. Looking to our recent experiences, organizations ur-
generic in nature, and for instance adopting lots of information security common criteria, needs to balance the risk exposure with cost for security. Some security measures can result in exploding cost and thus must always be taken
IT infrastructure usage and create protection profiles
with a good business sense. Too often we hear from clients
[4] A.Happel and C. Ebert: Security in Vehicle Networks of
Dr. Christof Ebert is managing director at Vector Consulting Services. He supports clients around the world to improve product strategy and product development and to manage organizational changes. He sits on a number of advisory and industry bodies and teaches at the University of Stuttgart.
The Automotive world has to catch up in security engineergently need to build up some basic security expertise and
Vector Consulting Services is a globally active consulting firm
obtain adequate external support, specifically where secu-
with focus on optimizing technical product development.
rity meets safety. Mature development processes provide a
Renowned companies from automotive, information tech-
that they had been forced to use IT common criteria or
At the same time it is critical in this market to align the
good basis but need to be amended with security engineer-
nology, healthcare, transport and aerospace rely on the
code checkers which create massive overheads. Similarly to
approaches for safety and security engineering to stay
ing activities.
professional solutions for improving product development,
a MISRA standard which hardly anybody uses without
cost-effective >>Apply threat modelling as part of hazard and risk analysis >>Use security levels in relation to safety integrity levels,
This white paper is continuously updated and is in its latest
adapting to the specific environment, we need also to adjust security rules towards risks, cost and competences. Independent of the approach used, we noticed several ac-
e.g., different security aspects, e.g. authenticity, integrity,
tivities that support the introduction and the performance
confidentiality; relevance of assets and access options,
of security engineering in general (Table 1) [1,2,3,4]. We do
e.g. attack intensity
Activity
Benefits
Adapt the development processes to factor in security engineering activities.
Security engineering activities are known, scheduled, and executed smoothly within the
product strategy and in organizational change management and interim management. A subsidiary of the Vector Group
version available through Vector Consulting Services:
with over 1500 employees, Vector Consulting Services sup-
mailto:
[email protected]
ports its clients worldwide with sustainable consulting solutions covering the entire product life cycle and the related
References:
processes and tools. The firm is managed by partners. This
[1] Ebert, C.: Global Software and IT: A Guide to Distribu
assures independent and customer-oriented consulting.
ted Development, Projects, and Outsourcing. ISBN: 978-
Details and further information:
0470636190-368. Wiley, Hoboken, NJ, USA, 2012.
www.vector.com/consulting
[2] S. Burton, C. Ebert, et al: Automotive Information Security. VDI, Baden-Baden, 2007.
“normal” development, not in an ad hoc way. Security is considered from the beginning on through the complete project. Additionally, synergies can be exploited (e.g. a configuration management process can prevent quick fixes that have not been tested against security vulnerabilities).
Systematically elicit
Elements that have to be protected are known from the beginning on, allowing for stringent
security requirements.
realization of their security. Additionally, security requirements can be used to deduce test cases for security validation.
Thoroughly review or test any security relevant artefact.
Reviews of security engineering artefacts such as security requirements and security concept as well as simulations of security functionalities and code analyses allow for the identification of vulnerabilities at the earliest possible time.
Use analysis and test
Automated tools reduce effort and allow for efficient and comprehensive analysis and
tools.
(regression) testing. For instance the Vector PREEvision PLM and modelling environment provides a strong collaborative engineering backbone for ensuring application of above measures along the life-cycle.
Manage embedded
Many activities of security engineering require a specific embedded security expertise, e.g.
security competencies.
identification of vulnerabilities, design of the security architecture, secure implementation,
Benefit from Vector Portfolio on Automotive Safety and Security Standard Software
Tools
Consulting
Technical measures to protect hardware and software security
Consistent approach for all development activities.
Support for methods and skills as well as the necessary cultural changes.
Examples: Robustness and Hardening in AUTOSAR, Security adjusted to safety integrity needs
Examples: Threat and Hazard analysis during concept definition, consistent modeling in PREEvision
Examples: Security engineering, culture change, hazard analysis
performance of security tests, and review of security-related work products. Without this expertise, effective security engineering is near to impossible. Therefore, build up embedded security competence in your organizational unit or obtain it from internal or external providers. Table 1: Activities that leverage security engineering
8/16
Figure 7: Benefit from Vector Portfolio on Automotive Safety and Security
8/17
Technical Article / September 2016
come only from the outside. Vulnerabilities are caused by
ated by manufacturers. The times of individual functional
careless development processes, unsystematic releases,
units are gone, and the complex vehicle system demands
but also by deliberate errors, such as “back doors” and
solutions as they are already practiced today in complex IT
“master access”. Companies have to secure the entire sup-
systems, such as continuous software upgrades in a very
ply chain and in doing so deliberately change their perspec-
short time and of course “over the air” (OTA). Standards
tive. It takes the ability to think like an attacker and on this
foster fast learning from the IT by cross-fertilization and
basis take preventive actions as an engineer or manager.
thus prevent that errors are repeated in every industry
This protection must always work, especially when
again and again.
last-minute changes are implemented just before delivery,
Due to the high degree of interconnected functions in the
or variant regressions of a product appear years after the
vehicle but also to the outside by increasingly open inter-
original release.
faces not only a specific function is affected, but also other functions that belong to a system group and interact with
Cyber Security for the Automotive Industry Practical experiences on the application of Cyber Security Cyber Security highly impacts the automotive industry. The increasing complexity of systems way beyond the vehicle itself combined with open interfaces require rigorous risk management, continuous quality assurance, and a systematic development process. To foster a strong security culture, Vector has summarized here best practices in automotive cyber security. The article provides hands-on experiences from Daimler, Hella, Infineon, Porsche, Thales, ZF and Vector. Industry case studies emphasize how risk-oriented protection is implemented.
“Cyber security has arrived in all companies as a key chal-
Managing Director of Vector Consulting Services, gives a
lenge.” This is the summary of Dr. Thomas Beck, CEO of
clear signal. Each company must establish a risk-oriented
Vector, from his experiences with companies worldwide. In
cyber security management that works reliably and trace-
2007 when the Vector Group presented in Baden-Baden
able throughout the whole life cycle for its products, pro-
and spoke for the first time regarding the growing rele-
cesses and supply chain. Experiences at Vector show that
vance of security in the context of functional safety with a
security is often limited to organically grown individual
practical contribution and own solutions, many companies
measures such as encryption. Crypto solutions, key man-
had argued that security is no issue in the automotive area.
agement, code analysis, fuzz testing and firewalls are nec-
This attitude has changed completely, as the recent Vector
essary, but their value is meager as long as vulnerabilities
Symposium 2016 showed. The widely attended Stuttgart
remain insufficiently addressed, be it consciously or uncon-
Liederhalle assembled car manufacturers, suppliers and IT
sciously. About 90 percent of all security related incidents
companies to share their experiences on cyber security.
are due to human errors according to the experiences of
Excerpts of the event and many practical tips are provided
Vector when surveying customers.
in this article.
The answer is a risk-oriented culture where security is spec-
Holistic approach
this specific function. This includes non-electrical charac-
Cyber security across industries has become a high com-
teristics. For example, a warning of mechanical problems
mercial risk, since there is no absolute protection against
or wear-out may no longer function after a functional inci-
hackers and abuse. Lorenz Slansky of Daimler AG under-
dent or attack on a bus system. Masahiro Goto and Martin
lines that cyber security is increasingly important for a
Prisching of DENSO showed that safety and security
brand, and consequently constitutes a competitive advan-
aspects must be considered as a pair. To achieve this, the
tage. For critical systems, such as in-vehicle information,
attack tree analysis (ATA) is supplemented by the Fault
security is highly relevant and cannot be compromised by
Tree Analysis (FTA) in order to systematically cover both
insufficient usability. Key issues in the development of pro-
type of risks. It is obvious for them that “all layers of the
tective systems are the complete identification of security
security architecture must be addressed for continuous
requirements, the systematic implementation of security
security to achieve the well-known concept of ‘Defense in
functions and security checks with the goal of consistent
Depth’. Figure 3 shows with the example of Cooperative
evidence that all the relevant security requirements are
Adaptive Cruise Control (CACC) how various security mea-
met. Security standards such as SAE 3061 help to learn
sures protect against threats in the network.
from other industries and thus quickly implement essential
Katharina Lohmann of Hella observes specifically in verifi-
solutions. Lorenz Slansky knows that proprietary mecha-
cation and validation a huge need to move forward. While
nisms often pretend just supposed security and clarifies:
process frameworks such as SPICE are used to systemati-
“Security by obscurity does not prevent hackers, but delays
cally prevent errors in engineering and maintenance, there
good solutions” Dr. Christian Meineck of Porsche AG adds:
is an urgent need to improve verification such as systemat-
“Security concepts must consider the vehicle and the IT
ically scanning each new software regression before
networks inside and outside the vehicle.” Figure 2 shows a
further testing and delivery, as well as introducing new
subset of typical attack scenarios, and how they are evalu-
testing procedures as fuzz testing and penetration testing.
ified across functions, systematically developed and con-
8/18
There is no absolute security
tinuously verified and validated. Figure 1 depicts this value
“There will be no absolute security, since each complex sys-
chain, emphasizing in particular on dangers arising inter-
tem bears defects.” This warning of Dr. Christof Ebert,
nally or externally. It would be naive to assume that attacks
Figure 1: Risk-oriented Security must consider the entire life cycle.
01
8/19 02
Article / September 2016 Cyber Security for Technical the Automotive Industry
Technical Article / September 2016
The companies agree that consistent risk-oriented security
strategy for sustainable support of various organizational
cannot solely be achieved by patches on ECU and network
units. Operationally this can be steered by a security man-
level. Security needs to address the overall architecture.
ager, who is responsible for the release of architectures and
Figure 4 shows the reference model of Vector with a clear
component releases. The traditional change control boards
separation of subnets. Between these subnets firewalls
need to be strengthened technically but also in the way
and intrusion detection systems are placed. Dr. Eduard
they are working, to evaluate the threats on the basis of
Metzker of Vector sees such distributed security architec-
defined criteria and assess different solutions before im-
tures under the current environmental circumstances as
plementation. Periodic architecture reviews and adjusting
the best way, because they can be implemented in a step-
the test strategy with focus on security will deepen the mu-
wise mode. This requires a layered security architecture as
tual understanding among developers and managers that
it is propagated by Denso and other Tier-1 suppliers. Start-
security measures are not a straw fire, but must be imple-
ing with a hardware-based anchor and AUTOSAR with its
mented in each single project. Such concepts cannot simply
state-of-the-art crypto solutions, the individual compo-
be imposed: They need strong anchor points in the organi-
nents are individually hardened. Dr. Achim Fahrner of ZF
zation. Vector reports from its projects that such behavior-
emphasizes in this layering the importance of a crypto-co-
al changes make security sustainable because the teams
processor and hardware security module (HSM) to build
have a tangible and concrete responsibility.
resilience and robustness bottom-up. The communication Figure 2: Attack scenarios in the vehicle.
Security needs systematic handling
should have no direct connection to infotainment and other
The cyber security projects of Vector give one clear mes-
vulnerable systems. This is especially true in ‘Over the Air’
sage: The line between systematic implementation of
Dr. Günther Heling of Vector highlights from his own expe-
Dr. Andre Weimerskirch of the University of Michigan em-
(OTA) upgrades that are increasingly being used. Axel Frei-
automotive cyber security and ineffective ad-hoc measures
rience in development and delivery of advanced AUTOSAR
phasizes. In the world’s largest field test of Public Key Infra-
wald of Infineon underlines that while OTA reduces the
is small and thus requires professional assistance. Security
basic software that only an automatic supply chain with
structure (PKI) for car-to-car (C2C) and car-to-infrastruc-
number of callbacks, it must also be carefully protected
attacks exhibit a common pattern where strength does not
rigorous release criteria creates the necessary quality.
ture (C2I) communication, he combined performance
before it is used in existing networks. Not only are the IT
exploit weakness but intelligence does exploit recklessness.
requirements and data protection. His logic is simple: “Pri-
requirements growing, such as rollback and availability, but
This means for instance errors in the configuration of fire-
Cryptography as a solution
ority one is functional safety, and priority two is privacy.”
also the secure distribution of software to the respective
walls and gateways, not fully coherent software changes,
Cryptographic methods are today an essential part of
Dietmar Hilke of Thales develops solutions for advanced
control units.
and complicated user interfaces so that security measures
security solutions. Klaus Schmeh of cryptovision assumes
security requirements. Design for security to his experience
Companies must strengthen their competences in cyber
remain in their default status and are thus vulnerable to
that the AES encryption procedure with 10 to the power of
is an important tool, and he cross-fertilizes medical immu-
security solutions, as well as systems and IT architecture in
attacks. On the basis of threat assessments, provisioning
38 possible keys will not be cracked in the foreseeable
nology with IT. Just as there are multi-resistant germs, the
order to progressively modularize the organically grown
dedicated infrastructure components and tools for verifi-
future even with quantum computers. A major challenge is
attacks are constantly developing new patterns. With sys-
architecture. At the same time they need to implement a
cation and monitoring, up to architecture reviews and
to integrate this and other security mechanisms in a mean-
temic resilience the resistance will be expanded continu-
ingful way to vehicle IT systems. High performance require-
ously. Security begins in design, but is a task for the entire
ments often contradict and eventually inhibit security, as
lifecycle – no matter how long that is.
Figure 4: Security by design in practice: Different subnets should be separated as much as possible
Figure 3: All Security layers are necessary for thorough protection
8/20
to safety-critical subsystems like steering and brakes
03
8/21 04
Technical Article / September 2016
security consulting Vector has gained wide experiences. Only a consistent life-cycle will facilitate cyber security: From the initial hazard analysis to architectural decisions,
Author Dr. Christof Ebert is Managing Director of Vector Consulting Services GmbH.
verification to regression tests at each new delivery and after-sales change management. That is also the impulse of Prof. Ebert of Vector: “Sustainable cyber security, that ought to be more than a flash in the pan, needs continuity and cooperation with professionals.”
Author Dr. Eduard Metzker is Solution Manager Security at Vector Informatik GmbH.
For more information on Cyber Security and Access to the mentioned presentations and videos, please visit: www.vector.com/security
Translation of a German publication in Elektronik automotive, special issue on Software September 2016 Image rights: Teaser image: Vector Informatik GmbH Image 1: Vector Consulting Services GmbH Image 2: Porsche AG Image 3: Denso Automotive GmbH Image 14 Vector Informatik GmbH
8/22
05
In conventional charging stations (Figure 1), a user inter
Since the vehicles do not need to carry enough energy to
face is generally housed in the charging station along with
last the entire day, developers were able to size the battery
the charging equipment and charging cable. This interface
capacity to be significantly lower, thereby reducing battery
might include a display module, controls for user inputs and
weight and size. This also leads to smaller moving masses
a credit card reader. In inductive charging, on the other
and makes them economical. Today, comparable projects
hand, not only is a charging cable no longer necessary; this
based on inductive charging technology are being imple
type of stationary user interface is no longer necessary either,
mented in local public transportation systems in many cit
because inductive charging is based on an operating philos
ies worldwide. In Germany, for example, there are projects
ophy that differs fundamentally. The drivers themselves
in Augsburg, Braunschweig, Mannheim and, starting in the
decide, from inside the vehicle, whether to draw energy
summer of 2015, in Berlin as well.
while underway, and they program their on-board electron ics according to their wishes. The exchange of information
New Approaches to an Old Transformer Principle
between the vehicle and the inductive charging infrastruc
Similar to charging at bus stops, it would be feasible to
ture is automated. When driving into a parking structure,
charge private electric vehicles at stop lights, at least in the
for instance, a guidance system could guide the car to an
urban environment. However, many challenges would have
available parking space that offers stationary charging.
to be overcome – with regard to both the technology and
While driving the car, dynamic charging is automatically
standardization – before such a scenario could be imple
started when passing through a section of roadway de
mented.
signed for this purpose.
Inductive charging is based on coupling between two coils – which is a principle from the classic transformer that has
Inductive Charging Gives Trigger to Future of E-Mobility ISO/IEC-15118 Standardization of Wireless Power Transfer In discussions and reports about electric mobility, the topic of inductive charging continues to grow in importance. Along with its primary benefit of convenience, this technology offers a number of key long-term advantages that cannot be overestimated. In particular, inductive charging makes it possible to conveniently extend the driving ranges of electric vehicles and design the expensive batteries to be smaller. This article offers an overview of current issues related to the technology and the standardization of inductive charging as discussed in such forums as the 2015 Vector E-Mobility Engineering Day in Stuttgart, Germany, which was attended by automotive OEMs and suppliers.
Pilot Projects Pave the Way
been known for a long time. Since a high level of efficiency
An Internet search will reveal that inductive charging is by
is one of the key factors for success, one criterion for an
no means new; rather it has existed for many years in the
implementation is that it should operate with a minimal
form of pilot projects and has been used in certain special
distance between the primary coil in the roadway pave
applications. One area of interest is driverless transport
ment and the secondary coil in the vehicle. Another import
systems, which have influenced processes in factory halls
ant criterion is precise positioning of the vehicle in order to
and warehouses for many years. This technology is also
minimize stray losses. Assistance systems for fine position
used to charge public electric buses in Turin and Genoa. In
ing will be of valuable service here.
these two Italian cities, around 30 electric buses have been operating in traffic since the year 2002. They are able to
Overcoming Technical Challenges
“refuel” by quick charging with power from inductive
Other technical issues relate to choosing suitable frequen
charging devices embedded in the road pavement when
cy ranges, charging current levels and coil voltages. These
they stop at bus stops (Figure 2). This method lets the
and many other parameters determine maximum charging
buses complete their daily routes effortlessly without hav
power, efficiency levels, allowable heating and other per
ing to explicitly charge their batteries during their operat ing hours or make extra trips to battery exchange stations.
Just as vehicles with a combustion engine make regular
charging. This means that along with usual charging while
trips to the filling station, electric cars must regularly draw
the vehicle is stationary, it is also technically feasible to per
their energy from an electrical outlet – whether they are
form dynamic charging while driving on specially prepared
charged overnight by plugging it into an electrical outlet in
roadways. Numerous businesses, institutes and research
a garage at home or on the road at an accessible public
projects are already working on advancing the technology
charging station. To date, there are no standardized
of inductive charging to market maturity while simul
methods that do not involve wire-conducted power trans
taneously achieving global standardization. Charging with
fer, which is always associated with manual actions for
out a wire connection leads to perceptible convenience ben
coupling plugs to a charging socket.
efits in everyday driving for users of electrically powered vehicles. Many other benefits are also realized: wireless
9/0
Inductive Charging Technology: Cutting-Edge Trend in
charging avoids defects in plug connections and cables due
E-Mobility
to aging, wear, corrosion or wire breakage, and this leads to
This will change in the future, because E-Mobility offers an
lower overall maintenance effort. In the public domain, the
alternative and supplement to wire-conducted charging in
lack vulnerable points of attack in the infrastructure also
the form of the advanced option of inductive charging. A
means significantly less damage can be expected from
distinction is made here between stationary and dynamic
vandalism.
Figure 1: Today’s conventional charging via charging station and cable
Figure 2: Inductive quick-charging of an electric bus in Turin, Italy – markings make it easier to position the vehicle precisely over the charging unit installed in the pavement
9/1
Inductive Charging Gives Trigger to Future of E-Mobility
formance data. Furthermore, various physical effects, para
In addition to ISO/IEC, other standardization organiza
the hardware interface (HomePlug Green PHYTM) and
ating facilities which are near expressways, and they could
sitic capacitances, isolation losses and many others must
tions are also working on communication solutions for
SLAC (Signal Level Attenuation Characterization) process.
supply electrical power to sections of roadway with induc
be considered. Despite all of the challenges, known projects
WPT, in particular SAE. This means that for every part of
The second step will be to perform migration to inductive
tive charging capabilities at a reasonable cost.
on inductive charging are achieving efficiency figures of
ISO/IEC 15118, there is a comparable part in the SAE stan
charging as soon as the ISO standard has prescribed the
around 90 percent. While the Italian pilot projects that were
dard. China, however, has not yet announced any national
necessary specifications for inductive charging systems.
Translation of a German translation published in emobilitytec,
installed in 2002 operate with a charging power of 60 kW,
Guobiao (GB) standard related to WPT. Nonetheless, har
Because Vector is represented on ISO subcommittees and
issue 4/2015.
electric buses that went into operation in Braunschweig in
monization of all national and international standards is
is actively involved in standardization, the Stuttgart-based
2014 obtain their energy at a power level of 200 kW. Both
necessary to achieve global compatibility of the charging
specialist is able to offer solutions and extensions for WPT
Image rights:
systems utilize a frequency of 20 kHz.
technology and charging communication. Organizations
in a very timely way. The same applies to test tools from
Figure 0, 1, 3: Vector Informatik GmbH
relevant to North America and Europe, SAE and ISO/IEC,
Vector that are used to test charging systems. For example,
Figure 2: IPT Technology
Charging Communication via ISO/IEC 15118: Standard
are in the process of creating a common standard for
the company offers a special VT7900 rack card with a
for Wire-Conducted Charging
Wireless Power Transfer. Now it is necessary to get Asia on
VT7870 adapter (Figure 3) for the VT System HiL tester. It
Any form of (public) inductive charging would be inconceiv
board, especially China.
can be used to support all of the mechanisms needed for
able without reliable communication between the vehicle
A draft international standard (DIS) for ISO/IEC 15118-6
Smart Charging Communication (SCC). They include
and the charging infrastructure. That is the only way to an
was released in early 2015, and DIS Part 7 and DIS Part 8
HomePlug GreenPhy communication with SLAC, PWM
swer questions of central importance – namely, who ob
should follow by late 2015 or early 2016. A complete Final
control (IEC61851) and suitable resistors for simulating
tained how much energy when and where and under what
Draft International Standard (FDIS) is planned for early
plug connections. The VT System can be used to simulate
conditions and to generate correct, legal billing documents.
2017.
electric vehicles or charging stations.
same requirements apply to charging via cable at charging
Embedded Solutions and Test Tools for ISO/IEC-15118
Summary and Outlook
stations. For wire-conducted charging (AC and DC), there
Automotive OEMs, suppliers and relevant businesses do
Global standardization is of tremendous importance in
is already the ISO/IEC 15118 standard that was fully re
not, however, have to wait until then to develop the charg
achieving a breakthrough in electric mobility and tapping the
leased in early 2015. There is also the DIN SPEC 70121:2014
ing infrastructure. Because inductive charging per ISO/IEC
mass market, and this applies equally to both conductive
standard for DC charging. Together they represent parts
15118-6ff is in large measure identical to wire-conducted
and inductive charging. A uniform global market lets the
the Combined Charging System (CCS – combined charging
charging, a stepwise approach is recommended. Finished
automotive industry and the producers of charging infra
system), which is the standard for AC/DC charging sys
and tested embedded solutions for ISO/IEC 15118 are al
structure sell their products internationally. It eliminates
tems in Europe.
ready available today from Vector, for example. Manufac
the need to implement special solutions for each part of
The ISO/IEC 15118 standard specifies all details related to
turers of production ECUs can use them to develop intelli
the world that drive costs upward. At the same time, this
charging communication for intelligent charging or smart
gent charging by wire. While the MICROSAR.V2G product is
would increase the resolve to make further investments in
charging, along with establishing a connection and authen
used to develop charging ECUs in the vehicle, the vEVSE
E-Mobility and offer assurance that the enormous develop
tication, negotiation of price rates, automatic payment,
product implements the related ISO/IEC-15118 conformant
ment costs would pay off. If electric vehicles could be imple
charging management and considerations for future smart
communication for charging stations. The solutions sup
mented internationally – and a standardized charging
grid requirements. If electrical grid power is in low supply,
port all software requirements of ISO/IEC 15118, including
infrastructure with broad coverage were to exist that in
Dirk Großmann Is a group leader in the area of Embedded Software at Vector Informatik. In his position, he manages such activities as the development of the Vector E-Mobility Solution. After obtaining a degree in electrical engineering from the University of Stuttgart and working in automotive ECU software development for 6 years, he joined Vector Informatik in 2003.
It should also be able to prevent fraud and misuse. The
charging management might have the electric vehicle tem
cluded wireless charging – this would have a positive effect
porarily feed energy back into the grid. ISO/IEC 15118
on user acceptance.
“HomePlug Green PHYTM” is planned as the physical layer
In practice, wire-based and inductive charging technologies
for data communication.
will presumably complement one another. What is import ant is to first implement nation-wide coverage of basic in
ISO/IC 15118 Extensions for Wireless Charging
frastructure for wire-based charging. Inductive charging,
Of course, it does not make sense to use wire-based com
on the other hand, offers a lot of potential for the future,
munications technology in inductive charging. Therefore,
but it requires substantial infrastructure modifications.
the physical layer (ISO/OSI Layer 1) must be changed. More
After international harmonization efforts have been com
over, it is necessary to modify the application layer (ISO/
pleted, it will become apparent just how willing investors
OSI Layer 7). Many ISO/IEC project teams are currently
are to support inductive charging infrastructure projects.
dedicated to these tasks and are developing the ISO/IEC
Dynamic charging solutions would let electric vehicles draw
15118 standard for Wireless Power Transfer (WPT) further.
energy wirelessly while driving on specially designed sec
Specifically, ISO/IEC 15118-6, -7 and -8 parts represent ex
tions of roadway. Over the long term, the positive effects
tensions of ISO/IEC 15118 for WPT. The draft for Part 6 of
of this approach can hardly be overstated. After all, this
the standard addresses general information on wireless
would significantly extend the driving ranges of electric cars, which are currently still limited. This might be accom
communication with WPT and defines application cases, while Part 7 addresses protocol requirements. Finally, ISO/ IEC 15118-8 specifies the physical layer as well as the data link layer.
9/2
Figure 3: VT7870 is the Smart Charge Communication module from Vector for ISO/IEC-15118 conformant tests of charging communication
plished by integrating charging segments at regular inter vals on expressways or intercity highways. Today, there are already many places in Germany that have windmill gener
9/3
Charging station
Realized through
functionality Communication
Frequency signal based on pulse
signal on the CP
width modulation (PWM). The PLC signal is modulated to the PWM signal, if necessary
Maximum possible
So-called proximity signal (PP),
loading of the
which is coded by a resistance
charging line
between PP and PE dependent on the cable cross-section in the connector
Provided current
Coding by the duty cycle of the PWM signal
High-level communi Duty cycle of 5 %. The duty cycle in cation capability
1- to 3-phase AC circuit, between
Vehicle
Realized through
functionality structure, charging in Modes 2, 3, and 4 always involves
Display of the plug
Resistance between CP and PE
IEC/ISO15118
low-level communication based on pulse width modulation
connection
that lowers the CP level from 12 V
Four modes are defined in IEC 61851 [4] for conductive
(PWM) via the Control Pilot (CP) connection. If the vehicle
charging of electric vehicles. >>In Mode 1, the vehicle is charged with a single-phase
and charging station support high-level communication,
PWM-based communication, in principle. Therefore, a com plete test system must handle both communication modes.
three-phase power supply with a maximum current of 63 A and a pilot signal provided by the charging station. >>Mode 4 describes DC charging with up to 400 V / 125 A.
Function of the Components Involved From the vehicle perspective, the functionality of the charging station essentially consists of the components de
9/4
While the Mode 1 charging operation does not involve com
scribed in Table 1. Table 2 presents the functionality of the
munication between the vehicle and the charging infra
vehicle from the perspective of the charging station.
tion. Finally, a complete test system must be able to meas ure and analyze the load circuit (AC or DC) in terms of cur rent and voltage, and disturb it in a defined way.
system must provide all interface variables in conformance with standards and with defined injected errors to each component to be tested. For the charging communication channels shown in Figure 1, the possible issues to test include: >>Control Pilot signal with incorrect characteristics on the PW component (e.g., level, resistance values, duty cycles, time sequences) and PLC component (e.g., structure of communication, communication conforming to
charging electronic control unit (EV-ECU) with simulated
environment is required.
32 A and a pilot signal. >>In Mode 3, charging takes place with a single-phase to
and charging station that take part in the CP communica
For the component test or robustness test of an EV
tions, and test reliability and robustness against various disturbances, consistent test case coverage with an open test
[3]. Every PLC-based charging communication requiresis
ground as well as variations of the resistances in the vehicle
standards, and defined faulty messages) >>Proximity Pilot including incorrect coding resistance
conformance to standards are ever more important. In order to test these issues, identify causes of charging interrup-
three-phase power supply with a maximum current of
nal short circuits and short circuits to battery voltage/
For component tests and analyses of robustness, a test
With the increasing diversity of electric vehicles and charging station systems, interoperability between components and
only possible in Modes 3 and 4 as described by IEC/ISO15118
signals completes the test system. This includes both inter
information, e.g., charging profiles,
Consistent Test Case Coverage for Electric Mobility
This is defined as power line communication (PLC) and is
necessary manipulation of the message contents of the PLC are required. The ability to inject errors into the electric
Communication of more complex
Table 1: Functionality of the charging station that the vehicle recognizes directly or indirectly.
of the CP based on the HomePlug GreenPHY standard.
and the PLC signal. In addition, creation, display, and if
communication
via separate cables
pilot signal. >>In Mode 2, the charging operation uses a single-phase to
and the communication signals, such as the Control Pilot
Participant in PLC
country. Alternatively: DC voltage
power supply with a maximum current of 16 A without a
must be able to analyze and emulate both the load circuit
Test Modes and Requirements for a Test System
100 V and 240 V AC, depending on
the corresponding signal is modulated to the PWM signal
levels, a special measuring and testing system is needed. It
exclusively for this purpose
Power
The Charging Process According to IEC 61851 and
In order to prove that charging is functioning properly at all
the range 3 % – 7 % is reserved
billing models, authentication
Smart Testing of Smart Charging
Test of the Charging Communication
to 9 V Display of the
Additional resistance between
connector interlock
CP and PE that lowers the PWM signal from 9 V to 6 V
Display of required
Resistance between CP and PE
cooling
that lowers the PWM signal from 6 V to 3 V
Participation in PLC Communication of more complex communication
information, e.g., charging request,
Power reduction
Agreement of a profile by means
account data, authentication of low-or high-level communica tion
EVSE (Figure 2), the following must also be provided: >>Vehicle wiring system voltage with overvoltage/under voltage, ramp characteristics, erratic disturbances >>Vehicle communication (e.g., CAN) with message errors and electrical errors >>AC or DC load signal with all types of voltage disturbances >>Grid Simulator for emulation of various grids around the world (different voltages, frequencies, mains with disturbances, etc.) >>Consumption of the DC charging power, if necessary >>For an EVSE test, the vehicle is simulated with all limit values (Figure 2). Also required are: >>Connection to a real or emulated power utility system (gridemulator) >>Simulation of the www environment, if necessary For execution of interoperability tests, the test system is inserted between the charging station and the vehicle (Figure 3).
Table 2: Functionality of the vehicle that is visible for the charging.
9/5
Smart Testing of Smart Charging
Figure 1: Interaction of charging ECU (OBC – Onboard Charger) and charging station (EVSE).
There are two possible modes of operation: in pure passive
the following tasks: test execution, simulation of PLC com
mode, only measurements are possible in the electrical sig
munication, provision of measurement and analysis data of
nals of CP, PP, and load circuit. In pure gateway mode,
the vehicle and charging communication and all electrical
where analysis and manipulation of the PLC messages in
characteristics, and control of the hardware components
high-level communication mode is targeted, it is necessary
involved. It enables all relevant measurements and signals
to disconnect, intercept, and modify as necessary the CP
to be provided with uniform time stamps and to be pro
line since the messages exchanged are encrypted when the
cessed, evaluated, and saved. The creation and manage
vehicle-charging station connection is established. In addi
ment of test cases, whether user-created [2] or standard
The VT System also represents the interface for vehicle
the EVCA. Additional power supply system analysis for
tion to measuring and influencing the communication and
ized, are completed in vTESTstudio of Vector Informatik [7].
communication and enables simulation of the vehicle pow
each of the three phases and each sine-wave period identi
load channels, a test system must have an execution unit,
The presented interconnection options enable test systems
er system and, if necessary, the control of an electronic
fies asymmetrical mains utilizations as well as mains dis
recording unit, monitoring unit and ideally an authoring
for subtasks to be derived from this architecture.
load or external power supply. The EVCA of comemso
turbances that can cause electromagnetic interferences of
and managing unit for test cases. There is already a large
For simulation of the environment of the charging ECU
GmbH is also able to detect all disturbances of the complex
the communication signal.
demand for systematic tests [2] today. In order to address
and/or charging station, the presented system uses a com
CP and load signals in real-time while simultaneously de
While charging communication is based on Ethernet, all
this issue, IEC/ISO15118 [3] will provide Parts 4 and 5 for
bination of the EV Charging Analyzer / Simulator (EVCA)
tecting the sources of the disturbances. Because the pilot
variables measured with the EVCA are forwarded to
standardized test cases in the future.
of comemso GmbH [5] as well as the VT System of Vector
signal together with the modulated PLC signal can violate
CANoe via a separate CAN channel. Only through the com
Informatik [6]. Both the EVCA and the VT System are able
the specifications for the pilot signal in the standard, spe
mon and time-synchronized measurement and visualiza
Overall Test System
to uncouple the PLC signal of the high-level communication
cially developed analog filter circuits are required to achieve
tion of the load circuit, CP signal, and PLC signal, related
To cope with the complex demands on an overall test sys
from the CP signal and to route CANoe over Ethernet.
interaction-free separation of the high-frequency PLC sig
disturbances and – if necessary – causes and effects can be
tem, a modular test system architecture was selected that
With the help of the Smart Charging Communication
nal from the pilot signal. For analysis of the CP signal, the
identified.
meets all necessary requirements, while allowing realiza
(SCC) add-ons, all necessary analysis and manipulation
EVCA uses a specially developed measuring procedure in
For field use, the mobile version of the comemso EV
tion of subtasks through targeted reduction of the system
possibilities are available in CANoe [1].
which up to 150 different errors and permutations thereof
Charging Analyzer / Simulator (EVCA) and Vector CANoe.
setup (Figure 4).
The EVCA and the VT7870 module of the VT System pro
can be measured in each period.
Ethernet with vTESTstudio are used (Figure 6). This pro
The central software element is the CANoe tool of Vector
vide the circuitry for CP and PP required according to IEC
In addition, the current and voltage of the load circuit is
vides test case consistency from the prototype stage to the
Informatik GmbH with Ethernet option. CANoe takes over
61851-1 [4], including the possibility to inject errors (Figure 5).
measured precisely as true RMS on all three phases with
series product both in the lab and in the field.
Figure 2: Possible component tests.
9/6
Figure 4: Interaction of charging ECU (OBC – Onboard Charger) and charging station (EVSE). overlay on video image in the Multi-media Window.
Figure 3: Possible modes of a “Man-in-the-middle” operation for interoperability tests.
Figure 5: Test system components for SCC tests relating to IEC 61851 and IEC/ISO 15118.
Figure 6: Test system combination for mobile use.
9/7
Summary The test system architecture presented in this article en ables systematic testing of components involved in con ductive charging according to IEC 61851-1 [4] and IEC/ISO 15118 [3] for robustness, conformance to standards, and interoperability. The open vTESTstudio and CANoe test environment provides fundamental transparency and re producibility of the test sequences. The modular architec ture and the combination of the comemso and Vector tools allow operation with the real environment or a fully simu lated environment and any intermediate stage in between as well as operation in automated test cycles. With this analytical approach at all levels, maximum test depth is made possible – the cornerstone for robust and harmo nized components that will ultimately satisfy E-mobility
Dr. Kiriakos Athanasas is Managing Director of comemso GmbH. He studied communications engineering at HS Esslingen and later studied information technology/electronics. He received a doctorate in distributed computer networks in the area of system safety and functional safety of autonomous driver assistance systems and driving dynamics systems. After 12 years of experience in these areas at Daimler Research & Development, he founded comemso GmbH in 2009. comemso GmbH develops complex measure ment, testing, and electronic systems for e-mobility. Dr. Heiner Hild is Team Leader and Product Manager for the VT System at Vector Informatik, where he is responsible for development of the VT System and other I/O test hardware and their linkage to CANoe. He studied physics at the University of Stuttgart and received a doctorate in image processing and geographic infor mation systems. Before joining Vector Informatik GmbH in 2014, he worked over 10 years in automotive development on driver assistance systems.
customers. Translation of a German publication in EmobilityTec, December 2014. Literature: [1] Albers, T. (July 2011). Komfortables Laden. Elektronik automotive – Sonderheft Elektromobilität, p. 60-63. [2] Brosi, F., Reuss, H.-C., & Großmann, D. (2013). Commu nication Conformity Between Electrical Vehicles and Charging Equipment Pursuant to ISO 15118. 13th Stuttgart International Symposium Automotive and Engine Technol ogy. Vol. 2, p. 115-126. Stuttgart: ATZIive. [3] IEC/ISO15118. 2012. Road Vehicles – Vehicle to grid Communication Interface.
Shaping E-Mobility!
[4] IEC61851-1. 2010. Electric Vehicle Conductive Charging System – Part 1: General Requirements. [5] EVCA comemso GmbH. 2013. EV Charging Analyzer / Simulator. Retrieved on 2014-08-01 from http://www. comemso.de/index.php/de/produkte/ladesystem-analysator [6] VT System Vector Informatik GmbH. 08 2014 Modular
Fast and efficient implementation of smart charging solutions
Test Hardware: VT System Retrieved 08 2014 from http:// www.vector.com/vi_vt-system_de.html [7] vTESTstudio Vector Informatik GmbH. (2014). Vector. Retrieved on 2014-08-07 from http://vector.com/vi_vteststudio _de.html Image rights: Vector Informatik GmbH Links: Homepage Vector: www.vector.com Homepage comemso GmbH: www.comemso.com
Benefit from Vector solutions for development of your charging ECUs, charging stations, and inductive charging systems: > Accelerate time to market for functional communi-
> Maximum test depth for mature products – scale
cation solutions – with series operation-proven
the test scope from development tests and integra-
embedded modules according to ISO/IEC-15118 and
tion tests to system tests with external power
DIN SPEC 70121 > Reliable support of AC and DC charging with the EIM and PnC profiles with certificate handling > Complete simulation of charging infrastructure, of individual ECUs, or the network behavior of the vehicle
electronics > Extensive analysis, measurement, and logging functions make troubleshooting easier More information & know-how: www.vector.com/ev
Discover the future with tailor-made ECU software and comprehensive test systems.
9/8
Vector Informatik GmbH | Germany · Austria · Brazil · China · France · India · Italy · Japan · Korea · Sweden · UK · USA | www.vector.com
HomePlug Green PHY: a Single Cable for Energy and
At the beginning of communication establishment, the
Data
vehicle sends an Ethernet broadcast message to all possi
A basic prerequisite for smart charging is reliable informa
ble network nodes. All charging stations that receive this
tion exchange between the vehicle and charging station. In
signal respond with an Ethernet unicast confirmation.
this regard, ISO/IEC 15118 provides for HomePlug Green
Since multiple charging stations can be supplied by one
PHY as the physical layer. This is a PLC (Power Line Com
physical supply cable, the protocol is responsible for identi
munication) method derived from HomePlug AV. The latter
fying the relevant charging station to which the vehicle is
is widely used in homes for networking computers and
connected. Unfortunately, other charging stations not
audio/video components via a home’s existing electrical
physically connected to the vehicle can also respond due to
wiring. Well-known Internet protocols from the IT world,
undesired coupled-in noise. The so-called SLAC mechanism
such as TCP, UDP, IPv6, DNS, DHCP, are TLS, are all built on
(Signal Level Attenuation Characterization) of HomePlug
this. The initial establishment of a connection for the power
Green PHY ensures a correct and reliable process for iden
line communication is described in more detail in the fol
tifying the physically connected charging station. SLAC
lowing.
works according to the request/response method in which the request always comes from the electric vehicle. At the
Smart Charging – A Key to Successful E-Mobility
SLAC Ensures Reliable Establishment of a Connection
same time, the vehicle and charging station agree on a
Within the scope of high-level communication according to
RunID – an unique identification feature that must be
ISO/IEC 15118, the initial establishment of a connection
contained in all subsequent messages of the same SLAC
between the vehicle and charging station is a critical event.
session.
As soon as a driver connects his/her vehicle to a charging
The establishment of a connection via SLAC runs sequen
station, the initial objective is to join a secured AV Logical
tially through various phases such as the “Sounding Phase”,
Network (AVLN). Each AVLN is represented by a Network
“Attenuation Characterization Phase”, “Validation Phase”,
ID (NID). In addition, each node of an AVLN requires an
“Matching Phase” and “Amplitude Map Exchange Phase”.
NID-matching network membership key for encrypted
Based on signal attenuations of various degrees, the vehicle
communication.
is able, with the help of the SLAC mechanism, to identify which charging station out of the many responding charging stations it is physically connected to. At the end of
Development and Testing of Charging Electronics Conforming to Standards
this process, an electric vehicle and charging station form a shared AVLN over which the higher protocol layers ex
Electric vehicle charging with AC current has been governed by the ISO/IEC 15118 international standard since it was
change encrypted information.
fully adopted in spring 2014. For DC current charging, the industry has agreed on an applicable subset, which is described in DIN SPEC 70121 (Prestandard procedure). This article sheds light on some details of the two standards and points out
Embedded Systems for ISO/IEC 15118 Charging
ways that manufacturers of electric vehicles and charging stations can quickly develop and effectively test products
Controllers
conforming to the new standard.
A major challenge for the automotive industry on the one hand and the manufacturers of the charging infrastructure
9/10
Fueling a combustion engine vehicle is not very spectacular
extended over several hours until after work or the end of
on the other hand is the designing of products that con
and is over within a few minutes. The corresponding opera
an extended shopping trip?
form to ISO/IEC 15118. The fastest way for automobile
tion for electric vehicles is quite another matter. Managing
Smart charging according to ISO/IEC 15118 offers the op
manufacturers to achieve functional results when develop
and optimizing the process of charging the battery is one
portunity to address these challenges in the best possible
ing the charging ECU is to use ready-made, field-tested
of the primary tasks of vehicle and charging station manu
way in terms of vehicle owners, energy suppliers, charging
embedded solutions such as MICROSAR V2G (Vehicle-to-
facturers. In the context of the changeover to alternative
station manufacturers, and last but not least, the environ
Grid) of Vector. MICROSAR V2G (Figure 1) is a cluster of
energy sources and the future smart grid, the charging op
ment. Uncontrolled charging processes in which users sim
basic software modules and is part of an AUTOSAR-com
eration is much more complex than it might appear at first
ply connect their vehicles to the available power supply sys
patible product line, which allows users to assemble an
glance. It is necessary to consider not only basic informa
tem in order to charge them with maximum possible power
ECU software package that is tailored to their exact re
tion such as the power available at the charging station,
will soon become a thing of the past or will be available only
quirements. MICROSAR V2G covers all technologies and
the battery condition and the charging demand. However,
at a premium. Since electric vehicle charging re-quires rela
protocols on the various ISO OSI layers that are needed for
more complex information, such as the energy resources
tively large amounts of power, locations such as parking
charging with AC and DC voltage current according to ISO/
available at the time of charging, must also be taken into
garages that have a high demand factor can experience a
IEC 15118 and DIN 70121. This includes suitable hardware
account. Also important are aspects related to cost optimi
significant power demand. Intelligent charging processes
support for HomePlug Green PHY as well as implementa
zation, payment/billing modalities, and safety, as well as
take this into consideration and grant the power supply
tion of a future-proof TCP/IP dual stack for IPv6 and IPv4.
other questions, such as: How is the user authenticated?
company or smart grid the time needed to adjust to the
Does the vehicle need as much electrical energy as possible
changing load conditions. Blackouts during peak load times
in a short amount of time or can the charging operation be
can be reliably prevented in this way.
Figure 1: MICROSAR V2G contains the software modules for Vehicle-to-Grid communication.
The smart charging communication counterpart for manu facturers of charging stations is called vEVSE. Based on Embedded Linux, it contains all ISO/IEC 15118 and DIN
9/11
Smart Charging – A Key to Successful E-Mobility
70121-relevant components (SLAC, EXI, and message se
PLC and SCC (smart charging communication) methods,
performs the remaining bus simulation. The automated
quence).
digital and analog values of sensors and actuators must be
test cases can be defined with vTESTstudio – a powerful
Special attention must be given to the testing of smart
simulated so that the charging station side or vehicle side
test design and authoring tool (Figure 3).
charging developments. A charging ECU that ist equivalent
can be operated according to specification. A powerful re
to ISO/IEC 15118 and DIN 70121 not only has to be integrat
maining bus simulation additionally generates the events
Outlook
ed error-free in the vehicle’s own electronics. Rather, it is
on vehicle buses, such as CAN, together with the underlying
The expected growth in the numbers of both electric vehicles
virtually open to the outside where it will confront a varying
ECU logic.
and charging station systems, which is accompanied by an
charging infrastructure involving different power compa
For testing of ISO/IEC 15118 and DIN 70121 developments,
increasing penetration rate for high-level communications,
nies and manufacturers. “Impasse situations” at charging
Vector offers a special plug-in SCC board for its VT System
will lead to enormous increases in combinatorial complexi
stations due to systems that are not fully compatible would
HIL tester. The VT7870 Board (Figure 2) provides two oper
ty. This will create challenges in terms of interoperability of
be highly counterproductive and a serious setback for ac
ating modes and is suitable for testing both electric vehicles
charging stations and vehicles and in terms of conformity
ceptance of electric mobility. In order to track down all con
and charging stations. When vehicles are tested, the HIL
to applicable standards. To successfully overcome these
ceivable errors and incompatibilities, a high level of test
system simulates the charging station, and when charging
challenges, a reliable and well-developed product and test
coverage and testing depth is needed. This can only be
stations are tested, it simulates the vehicle electronics. The
ing strategy is needed, as are mutually coordinated compo
achieved by using systematic and automated test runs
board contains a Devolo dLAN Green PHY module with
nents and tools. The presented line-up of products and ser
with powerful HIL (Hardware in the Loop) systems, for ex
QCA7000 chip set that is used not only to receive the sig
vices by Vector represents a universal approach that as
ample.
nal of the power line communication modulated for the
sures successful expansion of electric mobility.
control pilot but also to generate this signal (Figure 2, text Mastering New Kinds of Test Requirements
box below). The VT System has a modular design, can be
Translation of a German publication in Elektronik automotive, special issue E-Mobility, July/2014
Smart charging involves several new technologies that the software support for all methods used in ISO/IEC 15118
Functions of the VT7870 Hardware Module: >>Simulation of charging station or vehicle
Image rights:
and cover all the test cases needed in this context. This ex
>>PWM Control Pilot (CP) communication
Vector Informatik GmbH
tends across all ISO OSI layers from the physical layer of
>>High level power line communication (PLC)
the PWM signal modulated for Power Line and HomePlug
>>Error simulation on Control Pilot
Links:
Green PHY and mechanisms such as SLAC to Internet and
>>Simulation of component tolerances
More information about Vector’s solution for E-Mobility on:
Ethernet technologies. A high-performance HIL system is
>>Connection and measurement of the proximity
www.vector.com/ev
test system must handle. It must provide hardware and
able to completely and realistically simulate the environ
contact
ment for the system under test (SUT). In addition to the flexibly scaled, and is capable of simulating error scenarios, wire breaks, and short circuits. For charging tests with real amperages and voltages, controllable power supplies and
Dirk Grossmann is Team Leader for Embedded Software where he is responsible for development of MICROSAR V2G and vEVSE. He studied electrical engineering at the University of Stuttgart, Germany, and gained 6 years of automotive development experience in the area of ECU software before coming to Vector in 2003.
electronic loads can be connected. A PC with CANoe soft ware, Ethernet, and the SCC add-on package is used for configuring test scripts and for test sequence control, re port creation, and results analysis. If necessary, CANoe also
Figure 2: VT7870 is the smart charging communication module for ISO/IEC 15118-compliant testing of charging communication
9/12
Dr. Heiner Hild is Team Leader and Product Manager for the VT System at Vector. He studied physics at the University of Stuttgart, Germany, and received a doctorate in image processing and geographic information systems. Before joining Vector in 2014, he worked over 10 years in automotive development on driver assistance systems.
Figure 3: Example of automated test setup for onboard charger ECUs with simulated charging station
9/13
With electric charging, a new communication interface is
resource. One might say fine, but energy-saving systems
also assuming an important place in the vehicle: the com
are under consideration for vehicles with internal combus
munication between the charging station and the vehicle.
tion engines as well – the drivers here are goals and com
Just a few simple electrical signals suffice if communica
mitments to reduce CO2 emissions. Each vehicle should
tion is limited to control and verification of the actual charg
therefore consume as little energy as possible on the ECU
ing process. However, complex communication is needed
and network levels.
for more extensive functions. Such functions include auto matic billing for charging and integration of the vehicle in a
Energy Saving in the ECU Network
“smart grid” – i.e. cost-benefit optimized charging for the
In the development of ECUs and networks, various ideas
vehicle that is temporarily connected to the infrastructure.
are currently being pursued. Not all of these approaches
All around the globe, various development groups and
are new, but recently they are being addressed with high
standardization committees are addressing these issues.
priority and are making their way into standardization
Clearly assuming a central role here is ISO 15118, which de
(notably in AUTOSAR). >>In Partial Networking, logical networks are formed which
scribes intelligent charging with AC power. Communication is conducted over the power line (Power Line Communica
must conform to the physical networks. The energy-
tion), utilizes the Internet Protocol (IP) and is based on typ
saving sleep states are defined on the logical partial
ical Internet technologies (TCP/UDP, DHCP, XML, JSON, to
networks. They can be implemented more effectively in
name just a few). These technologies are indeed widely
this way, because fewer ECUs need to leave the sleep
used – every PC handles most of them – but implementa tion with the limited resources of an automotive ECU is
ECU Testing for Electric and Hybrid Vehicles Intelligent Measurement of Dynamic Current Consumption Electrically powered vehicles pose special challenges to test systems: in particular, ECUs must utilize electrical energy efficiently in development and testing. This requires measuring the current consumption of the ECUs as a function of software states – this is the only way to attain the required energy efficiency.
new. The testers are faced with new challenges as well;
constructed so that they appear to one another as
they now need to analyze these protocols and set up suit
active on the communication network, but they can
able test environments.
essentially go into a sleep mode internally. This is used
Another aspect: While communication in the vehicle previ
whenever the actual ECU functionality is not needed.
ously ran between known ECUs, now there is complex com
Extensions in the ECU hardware ensure that periodic
munication between the vehicle and a variable infrastruc
messages continue to be sent, and the ECU core is
based test of the vehicle interface is necessary. The same
awakened under certain conditions. >>The key word ECU Degradation covers all measures in
applies to the charging stations. In the future, uniform test
which unnecessary parts of the ECU are deactivated.
content might be arranged (key word: Conformance Test).
This ranges from simple switching off of electrical driver
ture. To assure troublefree operation in the field, a broad-
Certainly, some aspects are still in flux with regard to stand ardization; however, adequate tests must still be developed for ongoing vehicle projects.
9/14
state in many operating states. >>In Pretended Networking, individual ECUs are
stages to fine-granular control of chip-internal logic units. GPS signals (optional). >>Merging of different functions into just a few ECUs not
Power-saving technologies play a central role in the devel
only reduces overall energy requirements, but also offers
opment of electrically powered vehicles. In the conflicting
savings potential in hardware costs. AUTOSAR method
The research conducted by the advanced development and
New Challenges in e-Vehicles
priorities between range, available battery technologies
ology already supports this approach in its distinct func
production development departments of automotive
The most noticeable change in on-board electronics is the
and system costs, electrical energy is an extremely scarce
tional perspective. High-performance multi-core proces
OEMs and suppliers show that much work is clearly being
new ECUs for the electrical drive components and the bat
done on electrically powered vehicles and related mobility
tery (Figure 1). In a fully electric vehicle, the engine control
concepts. Some products have already advanced beyond
ler is replaced by a controller for electric drives. The trans
the experimental stage, while many others are prepared to
mission ECU has been eliminated, but a new battery man
follow shortly. This has put systematic testing of vehicle
agement system handles all aspects related to the battery
electronics into focus in accountable testing departments.
cells, and an on-board battery charger enables “refueling”.
During initial conceptual and prototype phases, existing
The testing departments can transfer existing test meth
components from conventional vehicles are often used,
ods to these ECUs. For the batteries and electric motors in
while the focus was on the electrical powertrain and inno
particular, suitable environment simulations must be inte
vative functions. However, in production development of
grated in the test benches. On closer examination, this
initial electric and hybrid vehicles, it is now necessary to
turns out to be a great challenge, because the high volt
transfer important findings of the past decades related to
ages used in the electrical powertrain have a tremendous
E/E architecture validation to the new electric vehicles.
influence on the test bench equipment. The primary chal
What is different in testing vehicle electronics in electrically
lenge is to attain the same testing depth and the same
powered vehicles? How do established test strategies need
degree of test automation for the new systems under these
to be changed, supplemented or even replaced?
conditions as for known electronic components.
Figure 1: New in the e-vehicle are ECUs related to the electrical powertrain and the obligatory use of power-saving techniques on all levels.
9/15
ECU Testing for Electric and Hybrid Vehicles
Figure 2: The power supply module of the VT System determines the DUT’s current consumption with high measurement precision and time resolution.
the savings potential consists of many individual optimiza
read out from the ECU via diagnostic or calibration inter
tions, the tester must test very precisely whether the cur
faces. For example, a value on the internal state of the ECU
rent consumption meets expectations in the individual ECU
read via XCP could provide information in the ECU’s inter
states. The same applies to development: The developer
nal state. What is important here is that all values are
must be able to evaluate the current consumption in refer
available directly and with the same time base, as in
ence to the momentary software state.
CANoe. Suitable tool support makes it easy to evaluate
High-performance test systems such as the VT System
ECU behavior (Figure 3). This is particularly necessary in
(Figure 2) from Vector therefore enable precise acquisition
the development phases and during debugging. Using the
of the current consumption of the ECUs under test and
same basic approach, it is also easy to formulate test
permit correlations to system states. The modular VT System
programs and automate the tests. Even in E-vehicles, test
test hardware simulates the sensors and loads, stimulates
ing departments can thereby attain the same high level of
the inputs and measures the output signals, generates
automation that has proven to be a key component of
electrical faults such as short circuits and line breaks, and
validation strategies in recent years.
permits toggling between internally simulated and exter nally connected sensors and loads. Moreover, the VT System
Translation of a German publication in: Automobil Elektronik,
sors are also more energy-efficient than equivalent indi
controls the supply voltage and measures the consumed
August/2011
vidual processors in dedicated ECUs. >>Development could even go a step further and combine
current. Fast, automatic range switching ensures that very high currents while operating under load, as well as mini
Image rights:
multiple logical ECUs into one physical ECU by means of
mal currents in power-saving and sleep modes, can be
Vector Informatik GmbH
a virtualization layer. However, the savings potential
measured with high resolution.
comes at the risk of unknown mutual interactions.
With the VT System, CANoe handles automation of these
Links:
tests. This software simultaneously permits simulation of
Homepage Vector: www.vector.com
The refined techniques designed to attain energy savings
the rest of the network nodes (remaining bus simulation)
Product Information VT System: www.vector.com/vtsystem
increase the complexity of ECUs and networks. That is why
and services software accesses to the ECU. Furthermore, it
systematic tests introduced early in development phases
contains comprehensive analysis functionalities, so that
are more important than ever.
developers can use the system for testing and debugging.
Dr. Stefan Krauß is a group leader at Vector Informatik GmbH in Stuttgart. As Product Manager he is responsible for the VT System.
CANoe was specially developed for analysis, simulation and Testing Current Consumption in a Differentiated Way
testing of ECUs and networks, and therefore it is able to
The current consumption of ECUs plays a key role in test
act as a communication partner for the various charging
ing. Previously, current consumption was acquired as a
station interfaces. In testing a charging ECU, the charging
mean total value, or it depended on relatively static operat
station is simulated – and vice versa.
ing modes, e.g. the key word Sleep Mode. In consumption-
Testing and analysis require that various signals be used to
optimized systems, however, it must be determined
determine the system states of ECUs and networks. They
dynamically in relation to the ECU’s software states. Since
may be bus signals, hardware signals or information that is
Figure 3: In CANoe, power consumption and the ECU state are clearly displayed and easy to analyze.
9/16
9/17
evant OEM extension to create the remaining bus simula tions or gateway routing with just a few mouse clicks, and they are then loaded to the interface hardware. To inte grate standalone applications in other systems, the Ether net/UDP based interface known as FDX (Fast Data Ex change) is available. It permits quick write and read access es to bus signals and system variables. Prepared CANoe/ CANalyzer standalone configurations are loaded to the in terface module from any desired PC via a manager. This process can also be automated for optimal integration in a suitable environment. EV/HEV Rapid Prototyping: Universal Bypassing Solution The bypassing solution from Vector lets users execute parts Figure 1: Comparison: range of uses of conventional interface hardware versus the extended range of uses for VN8900 systems.
of the ECU software outside of the ECU with deterministic response times, i.e. on the VN8900. This especially makes sense in EV/HEV development if: >>Functions need to be modified quickly without running
CANape. These challenges are addressed by distributing work between the host PC and the intelligent interface hardware. Only relevant tasks are executed directly on the
New Bus Interfaces for Electric/Hybrid Vehicle Development The many different bus systems used in the development of electric/hybrid vehicles (EV/HEV) are pushing conventional hardware interfaces to their performance limits. A crucial factor in determining testing depth, analysis quality and simulation options is the degree of real-time performance in data exchange. Communication between vehicle networks and the test and simulation tools is of primary importance here. To satisfy these heightened requirements, Vector has added a modular high-performance interface with integrated real-time computer to its interfaces product line. This interface’s real-time performance leads to short deterministic cycle and response times and enables flexible use in the EV/HEV development field and in numerous new application areas. An ideal hardware interface for EV/HEV development is
maining bus simulations and gateway applications in real
characterized by excellent real-time capability, easy han
time. New application areas are also emerging in ECU de
dling with such features as plug & play via USB, extendabil
velopment; of particular interest here those that satisfy
ity and maximum versatility in potential uses. These some
the stringent requirements of electric/hybrid vehicle devel
what contradictory requirements could not be satisfied by
opment. It should be emphasized that rapid prototyping
previous concepts.
requirements (prototype ECUs and bypassing) are sup
through the entire ECU code generation and flash process >>Functions need to be switched easily for comparative measurements >>New functions cannot be executed with the existing ECU
real-time capable hardware interface, while other stan
hardware, e.g. if it lacks sufficient memory or CPU
dard tasks such as data preparation, storage and visualiza
performance.
tion are run on the host PC as usual. In the ECU, it is also necessary to have the function to be Standalone Operation Opens up New Application Areas
bypassed “cut loose,” i.e. it is no longer executed. Input and
If no user interactions are necessary, remaining bus simula
output parameters of the bypass function are typically
tions and gateway applications can be autonomously exe
located in the ECU’s RAM, and they need to be transferred
cuted on the interface hardware. Remaining bus simulation
as quickly as possible to the bypass computer. The stan
capability is absolutely essential in developing and testing
dardized protocols CCP, XCPonCAN, XCPonFlexRay and
of individual ECUs, even if some of the electric or hybrid
XCPonEthernet are all candidates for the bypass transfer
vehicle’s ECUs are unavailable. CANoe is used with the rel
(Figure 2). The VX1000 measurement and calibration sys
ported, which are located earlier in the development pro Interface with High-Performance CPU Core
cess (left side of the V diagram). This will be addressed in
Therefore, in developing its latest generation of interfaces,
more detail later. A significantly longer time span is covered
Vector took the approach of implementing active hardware
in the ECU development process than when conventional
architecture with an integrated CPU. The resulting solution
interface hardware is used (Figure 1).
covers fundamental uses such as bus analysis, remaining
9/18
bus simulations, high-performance measurement and cali
Real-time Execution of Remaining Bus Simulations and
bration over CCP and XCP, execution of gateway routing
Gateway Applications
relationships, quick flashing and execution of complex diag
Great challenges are posed by requirements for real-time
nostic services.
capability with very fast reaction times, a simple plug &
The VN8900 system’s many different interfaces and its
play connection via USB, and preserving comprehensive use
high-performance computing core let users execute re
of widely used Vector tools such as CANalyzer/CANoe and
Figure 2: Data flow diagram of the bypass solution
9/19
New Bus Interfaces for Electric/Hybrid Vehicle Development
Unlike existing solutions for ECU prototypes, no cross-com piler is used in the VN8900 approach. This means that all familiar and proven CANoe functions – such as network management, the interaction layer and transport proto cols (e.g. for diagnostics) – can be used directly in ECU simulation. In executable generation from Simulink models via a special CANoe target, an XCP driver can be compiled into the exe cutable. As a result, the VN8900 prototype runtime envi ronment over XCPonEthernet can be measured and cali brated quite easily with a calibration tool like CANape (Figure 3). Many VN8900 customers are developing more and more new application cases themselves. For example, the stand alone operating mode permits use for data logging without Figure 3: Measuring and calibrating VN8900 prototype ECUs
a host PC by utilizing the integrated 2 GB flash memory (approx. 1 GB available) or external USB connections for mass storage.
tem from Vector enables very quick access to an ECU’s
EV/HEV Rapid Prototyping: VN8900 as Prototype
Summary and Outlook
RAM. This process involves connecting a POD (PlugOnDevice)
Hardware Interface in Battery Control ECUs
In developing ECUs for electric/hybrid vehicles, users bene
to the ECU via Data Trace or debug interfaces such as
This application case is of special interest when no ECU
fit from the flexibility of the VN8900 interface solution,
Nexus, JTAG or DAP; in the VX1000 base module, the infor
target hardware is available. Today, this is frequently the
which has up to seven CAN, LIN and FlexRay channels as
mation is converted to the XCPonEthernet protocol and is
case for EV/HEV battery control ECUs, because it is impos
well as optional I/O hardware extensions. The integrated
transferred to the VN8900. Performance measurements
sible to re-use existing ECUs from previous models, and in
real-time core enables short and deterministic response
indicate a measurement data rate up to 100 times higher
most cases the ECUs must be completely redeveloped for
times. Because it can be used as rapid prototyping hard
than is possible with CAN. To measure the up to 50 kHz
electric/hybrid vehicles.
ware or for standalone applications, the VN8900 can be
drive signals of the electric motors, the VX1000 system is
In the CANoe standalone runtime environment, the ECU soft
used for a wide range of tasks over a many project phases.
frequently used in electric/hybrid vehicle projects, which
ware for this application case is executed on the VN8900 un
Finally, the numerous application cases with one and the
can then be easily extended to a complete bypass solution
der real-time conditions in the form of Simulink or “C” execut
same hardware and associated production volumes con
with the VN8900 hardware. An optional plug-in I/O board
ables. The communication with other bus nodes is via CAN,
tribute to making the VN8900 a cost-efficient solution,
in the VN8900 gives the bypass runtime environment
LIN or FlexRay bus interfaces. Other devices, e.g. sensors,
especially in the development of EV/HEV vehicle networks.
access to digital and analog signals.
might be connected via the digital and analog I/O interface. Translation of a German publication in Hanser Automotive, 03-04/2011 Links: Homepage Vector: www.vector.com Product Information CANape: www.vector.com/vn8900 Alfred Kless (Dipl.-Ing. (FH)) After graduating with a degree in Electrical Engineering at the College of Applied Sciences at Esslingen, Mr. Kless initially worked at ALCATEL, including as team leader for software development and business development of test systems. Since May 2004, he has been employed at Vector Informatik in Stuttgart as Business Development Manager for the “Measure ment & Calibration” and “Network Interfaces” product lines.
Figure 4: Using the CANape Simulink Model Explorer, the model can be visualized, and internal model parameters can be displayed and calibrated.
9/20
9/21
that utilizes lithium-ion batteries, the team was participat
etc. Since direct drives generate forward propulsion pre
ing outside of the regular competition, but under the offi
cisely where it is needed, the system attains an exception
cial oversight of the FIA (Fédération Internationale de
ally high efficiency of up to 98 %. This engine concept was
l´Automobile). The goal was to make the public aware of
awarded the Bosch Innovation Prize in the year 2006.
the performance capabilities of the direct drive system im plemented in the Schluckspecht vehicle. In the end, a driv
Optimized Commutation Strategy with PWM Drive
ing distance of 626.6 km on a single battery charge was
Control
officially documented, more than had ever been driven by
Because of their brushless operating principle, wheel-hub
an electric car under comparable conditions on public roads.
drives operate nearly wear-free, just like inverter controlled asynchronous AC motors, which are the quasi-standard for
Electric Mobility Makes Great Strides 626.6 Kilometers under Real Conditions on one Battery Charge Today, there are numerous research projects that focus on topics related to electric mobility. One aspect that is still considered a critical issue is the limited driving range of electric vehicles. The so-called “Schluckspecht” project holds special interest here; in the Solar Challenge 2010 in South Africa, a vehicle by this name covered 626.6 km – the longest distance an electric car has ever driven on a single battery charge in real traffic on public roads. This milestone was enabled by state-of-the-art drivetrain technologies and power electronics paired with highly professional implementation of the control and networking systems.
To build an electric car with a long driving range, optimiza
ticipating in the European Eco Marathon since 1998, for
tions are needed in all relevant disciplines. Necessary are a
example, a competition that gives special recognition to
drive with high efficiency, light and compact batteries with
the most energy-efficient vehicle. In 2008, the “Schluck
large storage capacities (energy density), suitable power
specht III plus” concept vehicle took first place in the fuel
electronics, well-tuned control algorithms and efficient
cell category with a low equivalent combined fuel con
network communication. Of course, weight plays a crucial
sumption of just 0.032 liters of Super gasoline per 100 km;
role here; this means that the mechanical construction of
this is equivalent to a distance of over 3,100 km on one liter
the chassis and body must be lightweight yet sturdy, and
of Super. Together with its research partners, the team de
finally, safety aspects and in particular an effective brake
veloped all key components of the motor, chassis and wheel
system must not be neglected.
suspensions and systems ranging to the vehicle electronics.
Wheel-hub Direct Drive with Iron-free Exciter Coils
industrial drive technology. One essential prerequisite,
The success story of the Schluckspecht IV E, a variant of
however, is electronic commutation, which ensures that the
the fourth generation of test vehicles, is based on a drive
directions of the magnetic fields in the coils attract and re
concept with wheel-hub motors, which the University of
pel the permanent magnets at the right times in alterna
Offenburg developed in collaboration with the Stuttgart-
tion, based on the fundamental operating principle of all
based engineering company Evomotiv. Together with its
electric motors. A prerequisite for this, and especially for
twelve lithium-ion battery packs, the vehicle weighs about
the starting commutation, is precise knowledge of the rotor
320 kg and is driven by two wheel-hub motors, each with
position. Several Hall sensors are used to acquire the posi
42 poles and two kW of peak power. It is an advanced de
tions of the permanent magnets. From this data, an evalu
velopment of the “Schluckspecht City” vehicle variant that
tion unit generates four tracks (A, B, Strobe, Index) via a
preceded it, and it achieves a high level of efficiency using
quadrature signal (Figure 2), which provide all necessary
brushless DC motors. In this motor type, the rotor has per
information on the turning direction and rotor position to a
manent magnets, while the excitation windings are located
downstream type TMS320 digital signal processor (Figure 3).
on the stator.
The signal processor, whose features include two CAN
A special aspect of the Schluckspecht motor is the iron-free
modules for interfacing with the on-board network archi
construction of the stator and excitation coils. Together
tecture, generates two PWM signals that are phase-shift
with the direct drive and a sophisticated drive control sys
ed by 180° (Figure 4) to control the power electronics. The
tem, this motor exhibits some interesting characteristics.
bridge transition can be used to switch each excitation
For example, there are no cogging torques at all, which
winding to the positive (T1, T5, T3) or negative (T4, T6, T2)
would otherwise occur in a conventional construction that
link and control the direction of the current flow or mag
is not iron-free. Periodic cogging torques cause mechanical
netic field. The project engineers and students use a rela
oscillations and speed fluctuations, and they reduce effi
tively high PWM frequency to compensate for the low mo
ciency. A crucial advantage – besides a higher start-up
tor inductance. From the perspective of the coil, the fre
torque and low-noise operation – is that the wheel turns
quency is switched four times per PWM cycle. Furthermore,
with hardly any resistive forces in the deenergized, exci
to recover energy during braking (regeneration), the sys
tation-free motor state; this makes it possible to omit a
tem can be switched between motor and generator modes
separation clutch as well as a transmission, differential,
by changing the duty cycle. The special aspect here is that
Encouraged by this and other successes, the team decided
9/22
College Project with a Long Tradition
to participate in the South African Solar Challenge, a com
The Offenburg University of Applied Sciences is also ad
petition for alternative drive vehicles. It is held on public
dressing this topic, and it can already reflect on over ten
roads around the Republic of South Africa, where many dif
years of experience in electric mobility with its “Schluck
ferent hill grades must be mastered. Because the “Schluck
specht” student project. Team Schluckspecht has been par
specht IV E” (Figure 1) is a purely battery-powered vehicle
Figure 1: Schluckspecht IV E at the Solar Challenge in South Africa.
Figure 2: Quadrature signal
9/23
Electric Mobility Makes Great Strides
it is possible to work with an optimized commutation strat
base for the network. The Vector Interaction Layer then
egy using the four alternating states at half of the PWM
ensures that every message is sent with the send type
frequency.
specified for it in the database.
Evomotiv and the Hochschule Offenburg each set up their own motor test benches for measurement and test pur
From Simulation to the Real ECU
poses, and to calibrate motor parameters independent of
At the beginning of the project, the development team
the actual vehicle (Figure 5).
used this method to simulate over half of the ECUs of the Schluckspecht. The ECU applications created with CANoe’s
Networked Electronics in the Service of Electric Mobility
own CAPL programming language provide the foundation
Basic elements of the Schluckspecht IV E electronic archi
for the remaing bus simulation for great depth of testing,
tecture are a central controller, a human-machine interface
even without a vehicle. To test the central gateway, for ex
(HMI) ECU and several battery control modules. The latter
ample, it seemed sensible to implement a special simula
continually monitor the voltage and temperature of the
tion interface. As the individual ECUs are gradually com
Figure 4: PWM signals for commutation
pleted, the related part of the remaing bus simulation is
batteries. The central controller regulates the network of wheel-hub motors as a function of driver inputs or the HMI,
Figure 6: System overview of the full vehicle.
and it also acts as the master for the battery control mod
simply deactivated. At the end of this process, the entire network is available in real form, and CANoe operates as a
ules. In its role as master, the main controller can shut down
slip. Electronic communication is distributed among the
pure analysis and monitoring tool (Figure 7).
the entire system very quickly in emergency situations by
CAN1, CAN2 and CAN3 buses. While CAN1 connects the
On test drives of the Schluckspecht IV E, the same configu
interrupting the energy supply. Moreover, this ECU serves
human-machine interface to the central controller, CAN2 is
tems that do not exist yet– at least significant portions of
ration that served as the basis for the remaing bus simula
as a central gateway (ZGW) for the vehicle’s three CAN
responsible for battery control. Because these two commu
them.
tion in the early development phase later served to monitor
buses (Figure 6).
nication areas are not time-critical, they utilize the Low-
This problem is solved by what is referred to as a remaining
processes inside the vehicle, and if necessary to intervene in
Vehicle control responsibilities include both safety engi
Speed transmission rate of 125 kBit/s. CAN3, on the other
bus simulation, in which appropriate software is used for
them. All nodes are deactivated in the Simulation Setup of
neering and vehicle dynamic control tasks. They are fulfilled
hand, is designed as a High-Speed CAN bus operating at 1
computer simulation of the ECUs that do not exist in real
the CANoe configuration, since all ECUs now exist in real
by providing a dedicated motor controller for each wheel-
Mbit/s, because it networks the motor ECUs.
form yet. The systems under test cannot detect any differ
form. On the competition drive in South Africa, engineers
ences between simulations and real ECUs; therefore, full
and student engineers monitored such parameters as the
the drive wheels when driving through curves – since there
Remaining Bus Simulation Enables Parallel ECU
network communication is available. On the Schluckspecht
temperature, voltage and current of the batteries, and they
is no mechanical differential – as well as monitoring wheel
Development
project, CANoe from the company Vector Informatik was
could set different drive torques over the various driving
During the development process for the ECUs and the soft
used as the standard analysis and simulation tool for this
stages. The HMI panel can be used to display and stimulate
ware, the participants at the University of Offenburg and
purpose. It is quite easy to create the remaing bus simula
the brakes and turn indicators.
its partner Evomotiv were confronted with the problems
tion using Windows software as soon as the responsible
that typically occur in complex communication structures.
designers have fully and correctly parameterized the data
hub motor. Vehicle dynamic control includes synchronizing
Typically, some developments are still in their beginning or prototype stages, while others are already further ad vanced. However, to test finished systems as realistically as possible developers must rely on the functionality of sys
Figure 3: System diagram of motor/converter bridge/processor
9/24
Figure 5: Motor test bench at Evomotiv.
Figure 7: CANoe as analysis and monitoring tool.
9/25
Remote Monitoring of Test Drives
Image rights:
Another interesting aspect of the Solar Challenge is that all
Offenburg University of Applied Science: initial figure
monitoring and control activities are performed from a
Evomotiv: figure 1, 2, 3, 4, 5, 6
support vehicle. The challenge here is to transfer data from
Vector Informatik GmbH: figure 7
the on-board vehicle network to the analysis computer in the support vehicle by wireless transmission communica
Links:
tion. This is accomplished by special CAN/WLAN interface
Homepage Offenburg University of Applied Science:
modules with a range of up to 500 m that effectively mirror
www.fh-offenburg.de
the entire CAN traffic of the test vehicle via WLAN to the
Homepage Evomotiv : www.evomotiv.de
remote network on the support vehicle. This process is fully
Homepage Vector: www.vector.com
transparent to CANoe; the tool can continue to be used to display and evaluate system parameters in the competi tion vehicle as usual. The time stamps of the CAN messag es, which are preserved in the transmission, permit (time-) consistent display on the receiving end. This is also possible over the opposite pathway, and technicians can stimulate the test vehicle’s network from the support vehicle. In this case, stimuli from the user control panel in the support vehicle have a higher priority for acting on the system than interventions by the driver. In extreme cases, the vehicle can even be fully operated by remote control. FlexRay Is Entering the Electric Vehicle Knowledge gained in these competitions quickly flows into advanced developments by industrial partners in the framework of knowledge transfer or into the university’s own projects. Evomotiv has long been working together with the scientists from Offenburg on an improved wheelhub motor for a street version of the electric vehicle. The focus here is on achieving a significant increase in motor power from two kW to 15 kW and four-wheel drive instead of two-wheel drive. For safety-relevant components, such as the brakes, various TÜV approvals are required. Here too, state-of-the-art technologies and innovations are ex pected to contribute to success. Consideration is also being given to a system with a voltage of 400 V to supply the motors instead of today’s 48 V system. Moreover, the use of FlexRay is planned for time-critical communication be tween ECUs, motors and the brake system and to imple ment the related control circuits. FlexRay – characterized by such features as high speed, real-time capability and fault tolerance – places significantly higher demands on participants’ expertise and on the development and analy sis tools that are used. Simulation and analysis systems like CANoe are especially in demand, since they combine high performance with multibus capability, and they can simul taneously process and display both FlexRay and CAN data. Translation of a German publication in Elektronik automotive, issue July/2011
Heiko Ruth has an engineering degree in Computer Science from the University of Applied Sciences at Esslingen. He has been working at Evomotiv GmbH since 2008. In 2009, he assumed the post of System Engineer for the joint project between Evomotiv and the Hochschule Offenburg. In this role, he developed the motor control system as well as the in-phase control of the prototype. Jochen Neuffer has an engineering degree in Information Technology from the University of Applied Sciences Esslingen. He has been working at Vector Informatik since 2002, where he is employed as a Product Management Engineer in the area of Tools for Network and Distributed Systems.
CANoe Safety-Related Lifecycle Validation of Battery Systems Case Study ZSW Laboratory for Battery Technology (eLaB)
The Customer
The Advantages
The ZSW Laboratory for Battery Technology (eLaB) in Ulm,
Endurance logging, data management and visualization for
Germany is an independent development and testing center
continual access to everything “at a glance” > Endurance tests of the battery and the BMS are very
for batteries. It is internationally recognized for its testing of cells, modules and complete battery systems including battery management. The laboratory’s researchers have over 25 years of experience with batteries and supercapacitors. Customers come from industry and research organizations worldwide. The Challenge Safety-related lifecycle validation of battery systems with increasing numbers of variants Endurance tests, which typically take months to complete, represent the foundation for reliable operation of a Battery Management System (BMS) and for long battery life. The
realistic > Non-stop operation of the test bench of over half a year ensures smooth test flow > Transparency achieved by clear traceability of log files to driving cycles and power profiles – both during operation and offline > Many different logging strategies based on userdefinable trigger conditions > Graphic visualization makes key battery parameters immediately and continually accessible at a glance > Targeted offline analysis is enabled by versatile and convenient search functions
tests contain real and synthetic performance profiles, such as emergency shutoff and charge cycles. The challenges are to strive for full automation in test flow and to handle the large numbers of test variants and large volumes of data. The CAN communication data alone amounts to terabytes. The Solution Combining an active power controller and CANoe to create a high-performance endurance test bench for batteries All power and communication interfaces of the System Under Test (SUT) are implemented in the battery test bench, which consists of the Battery Management System (BMS) and the battery (see figure). An active power controller can act as either a DC source or sink. Flow control in PC1 executes power profiles fully automatically. The CANoe test tool on the separate PC2 models CAN and LIN networks in a remaining bus simulation. The two systems communicate directly via the already existing vehicle bus. Visualization is provided on CANoe panels for continuous monitoring of the test progress. CAN-driven, CANoe subdivides the measurement results into binary log files of reasonable size and manages them. They can be traced
9/26
www.vector.com/contact
V2.0 | 2014-10
back to their associated endurance test at any time.
9/27
Providing the Energy
may be used for charging here. However, the charger must
Charging of EVs can cause a severe load of local electrical
be installed in the vehicle, which means additional weight.
distribution networks. Today’s electrical grids require some
In the second variant, the battery is charged with DC elec
time to react to such load changes. If several charging EVs draw
tricity. In this case, the charger is located outside of the ve
high power simultaneously in one location, e.g. in a parking
hicle, in the charging station, and it generates the DC volt
garage, this could lead to a local grid overload and outage.
age for charging the batteries. In this case, the weight of
Until now, no consideration has been given to the total
the charger does not matter, but costs are higher for such
power requirement for charging EVs on the electrical grid.
a DC charging station. Since these two charging processes
As soon as the driver plugs in the vehicle’s charging cable,
each have their advantages and disadvantages, they are
charging begins at the maximum possible current, and this
used in parallel.
adds a certain amount of load to the grid. This might ap
Convenient Charging of Electric Vehicles Smart Charging with MICROSAR IP Enables Flexible Charging Processes and Easy Payment Compared to conventionally powered vehicles, electric vehicles (EVs) have significantly shorter driving ranges due to the low energy density of their batteries. For EVs to experience a successful market launch, it is important to have a charging infrastructure in place that is widely accessible and easy to use. It is equally as important to have a standardized charging process. This article describes Smart Charging and its standardization in the ISO 15118 standard. With Smart Charging, in addition to a power connection, the vehicle also establishes a communication channel with the charging station. Today, Vector is already providing a first implementation based on its MICROSAR IP communication stack.
Today, charging of EVs generally takes place at home. Just
International Standardization and its Distribution
a few charging stations are available in public areas – as
Widespread establishment of a charging infrastructure
part of model studies. Since vehicles are parked frequently,
can only be properly achieved if all aspects of the charging
e.g. while shopping or at work, they can be charged during
process are standardized across manufacturers. The con
these times. In the future, a broadly based and standard
nector and cable as well as the charging communication
ized infrastructure will be built up for this purpose. It has to
must be standardized for all EVs and charging stations. In
offer a standardized mechanism for charging the batteries,
Europe, charging communication is described in the frame
and it must also support a method for easy payment. To
work of ISO 15118. In the USA, this is being done in SAE
enable convenient payment, debiting of the small amounts
(Figure 1). In Japan, there is already the CHAdeMO stan
should be conveniently handled by automated electronic
dard and a charging station network of over 250 stations.
billing.
According to the “National Development Plan for Electro mobility” by the German federal government, Germany should become the lead market for electromobility. This plan calls for one million EVs to be on the roads of Germany by 2020.
9/28
pear to be similar to the model of fueling up at a normal
Communication between Vehicle, Charging Station and
fuel station, where energy is always in stock and is easy to
Energy Provider
obtain in the form of gasoline. But the situation with elec
If the vehicle only has to communicate with the charging
trical energy differs fundamentally. It cannot be stored as
station for charging, the choice of transmission medium
simple as gasoline and be drawn from storage. Nonethe
and protocol would be quite flexible. However, the charging
less, by introducing an intelligent electrical grid (Smart
station and vehicle also need to communicate with various
Grid) and by using intelligent charging, it is possible to
servers on the Internet (Figure 2). Therefore, it makes sense
avoid overload and grid failure. In a Smart Grid, data is ex
to use the conventional protocols of IP-based networks. Since
changed about power requirements, and the electrical grid
requirements call for just using the cable for the charging
can be optimized accordingly.
current – and no auxiliary lines for communication – com
The power needed for a charging operation lies between
munication is implemented directly via the charging cable
3 kW and 20 kW, or even over 100 kW, depending on the
(Figure 3). PLC technology (Power Line Communication) is
available power connection and charging profile. By com
available for this purpose. In this system, the data stream is
parison, a typical citizen in Germany uses an average of
modulated onto the power line. This system is more familiar
3-5 kWh of daily electrical energy, depending on household
under the names Homeplug AV and IP-over-powerline in
size. To operate the grid so that it is more stable, the energy
the consumer products field; they offer a simple way to set
provider needs time to supply the charging energy. One way
up private computer networks via a building’s power lines.
to obtain this time is to delay the start of the charging op
In the vehicle’s charge control module, a TCP/IP stack is
eration by several tens of seconds.
used for communication. It provides socket communication over IP (Internet Protocol) for TCP (Transmission Control
Charging Method for DC or AC Power
Protocol) or UDP (User Datagram Protocol). Overlaid on
In charging the batteries, two different procedures can be
this protocol are several applications and protocols such as: >>DNS (Domain Name System) for name resolution >>TLS (Transport Layer Security) for encrypting the data
distinguished. First, the battery can be charged with alter nating current, which is available in the electrical grid as single-phase or three-phase AC. Nearly any electrical outlet
on the transport level
Definition of vehicle to grid communication interface Content
ISO/OSI Layer
Europe
USA
7 Application
ISO/IEC 15118 Part 1
SAE J2836
General information and use case definition
7 Application 6 Presentation 5 Session 4 Transport 3 Network
ISO/IEC 15118 Part 2
SAE J2847
Technical protocol description and Open Systems Interconnections (OSI) layer requirements
2 Data Link 1 Physical
ISO/IEC 15118 Part 3
SAE J2931
Wired physical and data link layer requirements
Figure 1: Charging communication is defined in ISO and SAE standards.
9/29
Convenient Charging of Electric Vehicles
this process, the vehicle and charging station regularly ex Electrical power provider
-
Battery charging unit
Charging station
+
state to reduce its own energy consumption. It periodically
(includes e.g. V2GTP)
Internet Internet
Smart Charging with MICROSAR IP
and the vehicle acknow ledges the reception of energy. During charging, the vehicle may be placed in a quiescent
SCC
Power cable with IP over Powerline Ladesteuergerät
change status information and electrical meter readings,
MICROSAR IP
wakes up from this state to execute a status update. The
TLS
charging itself continues without stop. When charging is
DNS
OEM
finished, the charging station shuts off the electrical power and unlocks the plug connection. The last acknowledged
TCP/IP
meter reading is transmitted to the energy provider over
(includes e.g. TCP, IPv4, UDP and DHCP)
the Internet for billing.
ETHIF
Paying by Micropayment
(Ethernet Interface) Figure 2: The vehicle uses the Internet Protocol to communicate with the charging station and servers on the Internet
As described at the beginning of this article, EVs have a
ETHDRV
short range due to the limited energy storage capacity of
(Ethernet Driver)
the batteries. To be equipped for unplanned or longer drives despite this limitation, efforts are made to charge the bat
>>V2GTP (Vehicle To Grid Transport Protocol), a new protocol for connection monitoring and data transfer
teries as often as possible and/or in a short period of time.
for use in motor vehicles and conforms to the AUTOSAR standard. In addition to the TCP/IP stack, the charger requires a CAN stack to connect to the existing vehicle
Furthermore, a module is needed that contains the Smart
network. Communication with energy management and
Charging functionalities from ISO 15118. For this purpose,
the user terminal are implemented via the CAN stack
Vector has developed its own standard module: SCC
(Figure 5).
(Smart Charge Communication.) It establishes the con
For example, full charging of a typical 20 kWh battery will
IP over Powerline
cost between 3 and 10 Euros, depending on the different rates. Often the amount is significantly less than this, be
AUTOSAR Modules
cause the battery is seldom entirely depleted and does not need a complete charge. So, a simple payment system is
IP-specific Extensions
needed that avoids the need to make small individual pay
Figure 4: The MICROSAR IP Stack from Vector contains modules to communicate over the Internet Protocol
nection to the charging station and exchanges parameters
Procedure for a Charging Operation
on the charging process over the connection. The module
On current EVs, the charging process is simple: the user
can be adapted to the requirements of specific carmakers
simply plugs a connector into the charging station, and the
and suppliers by its many different configuration options.
charging process starts right away. In Smart Charging per
Currently, data transmission over the Internet is generally
ISO 15118, the charging process is more complex. After
charging station and the vehicle are authenticated by cer
be based on electronic authentication and a suitable billing
still performed using the IPv4 protocol. To circumvent the
plugging in the charging cable, the vehicle first establishes
tificates. Data such as service information, rate tables and
contract with an energy provider – similar to a contract for
growing scarcity of addresses on the Internet, ISO requires
a connection with the charging station via PLC for commu
charging profiles is exchanged and selected over this en
a mobile telephone. The latter makes the most sense for
that vehicles and charging stations support IPv6. Overall, a
nication. Then the vehicle obtains an IP address over DHCP,
crypted connection, and payment modalities are set. Now
the small and unequal sums. As a side benefit, this also re
system is created in the vehicle that is very complex and
after which the SCC module queries the IP address of the
the cable is physically locked, so that it cannot be pulled
duces the risk of vandalism to charging stations in public
resource-intensive, but it is also very powerful.
charging station via a broadcast message (ChargePoint
during the charging process – as to prevent theft of the
spaces, because the charging station only requires a plug
Vector already offers an implementation based on the
Discovery). Now the vehicle establishes a TCP connection
electrical power. Finally, the charging station switches the
outlet and a small display.
MICROSAR IP stack (Figure 4); it was specially optimized
and, overlaid on this, a TLS connection over which both the
power on, which starts the actual charging process. During
ments for several short charging operations. In principle, there are a number of different possibilities for paying for the electrical charges: cash payment, payment by card and PIN or an automated billing method. This might
Charging Station
Electric Vehicle Control Panel
Charge Control Module SCC Figure 5: In
CAN Stack
CAN-Stack
Microcontroller Figure 3: Example of a charge plug as proposed for standardization.
9/30
IP-Stack
IP Stack
Microcontroller CAN
Microcontroller Ethernet/IP
addition to the IP stack, the charge control module also required a CAN stack to communicate with the control panel
9/31
The price for charging an EV cannot be given as a lump sum; price tables are communicated to the vehicle to calcu late the price. The combination of the price table, the charging profile and the available power at the charging station yields a number of variants for pricing and charging duration. The selected variant is based on pre-configura tion in the vehicle, so that charging can be started auto matically. Outlook Certain aspects of intelligent charging of electric vehicles may still seem like a dream. However, the foundations are already being laid today, e.g. in the framework of ISO 15118. Release of the ISO 15118 standard is scheduled for mid2012, with the goal of further expanding its range of appli cation. Extensions of the AUTOSAR-based basic software are also in planning or discussion. Vector is working on advanced de velopments as an active participant in ISO and AUTOSAR standardization committees to ensure that it can offer production-ready customer solutions in a timely manner. Translation of a German publication in Elektronik automotive, 07/2011 Image rights: Figure 3: MENNEKES Elektrotechnik GmbH & Co. KG, 57399 Kirchhundem, Germany All other Figures: Vector Informatik GmbH Thorsten Albers, Vector has been at Vector-Informatik since 2005, where he is employed as a software developer for embedded systems. For 3 years now, he has played a key role in developing the MICROSAR IP Stack for in-vehicle use.
9/32
Figure 1: The J1939 protocol essentially covers the Application Layer (Layer 7), Network Layer (Layer 3), Data Link Layer (Layer 2) and Physical Layer (Layer 1), so that it is no longer necessary to be concerned about communication details when working on the application level.
standard. For example, documents of the 7 series such as
field; although these bits do not replace the implicit priority
“J1939/71” refer to the Applications Layer, document
established by the CAN protocol, they make it possible to
J1939/21 the Data Link Layer, etc.
organize the Parameter Groups into up to eight J1939-specific priority levels. These priorities are used to adjust the
Networking Heavy-Duty Vehicles Based on SAE J1939 From Parameter Group to plug-and-play Application In networking ECUs in heavy-duty vehicles, it is the J1939 protocol that plays a key role. J1939 networks are based on the CAN bus (high-speed CAN per ISO11898); they are primarily used in powertrain and chassis components. The protocol creates a uniform basis for communication between electronic control units, and it supports the plug-and-play principle. Special J1939 tools and software components spare developers from needing to train in the details of the J1939 protocol, and they improve the quality of the development process.
The J1939 protocol – founded in the USA and defined by the
ardization aspects, J1939 gives OEMs sufficient freedom
Society of Automotive Engineers (SAE) – serves above all
for customized extension of communication. This is espe-
to preserve a uniform perspective and uniform handling of
cially important in promoting innovations, because no OEM
the most common vehicle components of various vehicle
wants to announce or discuss plans in working committees
types and manufacturers. In this context, it is interesting to
before their implementation.
CAN Message Format in J1939
priority to momentary application requirements at the
Although J1939 utilizes normal 29-bit CAN messages with
time the Parameter Group is transmitted – or during an
up to 8 bytes of data, here the CAN identifier quasi defines
optional ECU configuration phase. This makes it possible to
the mask of a uniform J1939 scheme (Figure 2). This is nec-
fine-tune communication to the application without the
essary to assure plug-and-play properties. The CAN identi-
SAE protocol permanently setting the priority when the
fier – besides identifying the useful data with the help of
Parameter Group is defined.
the Parameter Group Number (PGN) – also contains the J1939 ECU address of the sender and if applicable the ad-
The Name says it all: J1939 Device Names
dress of the receiver too. In addition, the three most signifi
J1939 defines device names that are each represented by a
cant bits of the CAN identifier are reserved for the priority
64-bit number. When an ECU is switched to active in the
note certain distinct differences between the European
10/0
and North-American heavy-duty vehicle markets. For ex-
ISO Layers Model decouples the Application from
ample, heavy-duty vehicle buyers in the USA have pre-
Transmission Physics
scribed to OEMs which components they need to install in
From the perspective of the ISO/OSI network model, J1939
specific vehicles. In Europe, on the other hand, it is the
is essentially based on the Application Layer (Layer 7), Net-
OEMs who fully define the design of the entire vehicle, in-
work Layer (Layer 3), Data Link Layer (Layer 2) and Physi-
cluding the components and their configuration.
cal Layer (Layer 1) (Figure 1). This lets developers work with
Besides using uniformly defined signals and data formats
signals without needing to be concerned about communi-
to communicate, it is of course important that receivers
cation details on the Application Level, such as details of
know how to interpret the information. Ideally, it should be
the transport protocols. J1939 documentation and defini-
possible to interconnect individual J1939 components
tion is oriented toward individual layers, and this is ex-
based on a plug-and-play scheme. Despite all of its stand
pressed in the names of the total of 14 documents of the
Figure 2: The J1939 message format – which is based on normal 29-bit CAN messages – requires some supplementation to achieve plug-and-play capability. The CAN identifier quasi defines the mask of a uniform J1939 scheme.
10/1
Networking Heavy-Duty Vehicles Based on SAE J1939
plug-and-play network, the device name serves to identify
on the other hand, are simultaneously addressed to all bus
Testing and Diagnostics of J1939 Components and
tures. When CANoe .J1939 is used consistently, the models
the device and its functionality. The device name is sub
nodes, which is practical when it comes to sending out
Systems
and databases created in the design phase not only serve
divided into different elements, between which certain de-
measured values, error handling and diagnostic purposes.
In view of the rising number of J1939 ECUs and the fact
as a foundation for simulation during development, but
that software solutions in heavy-duty vehicles are becom-
also for all tests accompanying development up to and in-
pendencies exist. The independent fields include the Industry Group and Manufacturer Code. The Industry Group is
Flexible Network Topology
ing increasingly complex, a systematic strategy for testing
cluding later diagnostic tasks (Figure 4). With the help of
used to establish the functions required in the network,
J1939 works with a passive bus that is terminated at each
and diagnostics also continues to gain in importance in the
simulated nodes, it is possible to set up and execute tests
since the J1939 protocol is not only used in conventional
of its two ends with 120 Ohm impedance. The advantage
J1939 field. Tests are indispensable in all development
for the ECU to be developed. The tests are further refined
heavy-duty vehicles but also in vehicles in the agricultural
here is that individual ECUs can be connected to the bus via
phases, from functional tests to integration tests to driving
during development and are used in verification of the total
and marine industries. Each ECU carries one of the SAE
branch lines with a length of 1 to 3 m. This enables flexible
trials in the total vehicle. It is well known that the later that
system.
assigned Manufacturer Codes that can be requested from
wire harness design, provided that a total bus length of
errors are detected, the more complicated and expensive it
that organization. Since each device also has a serial num-
40 m is not exceeded. Depending on the physical transmis-
is to correct them. However, it is generally only possible to
Extensive J1939 Test Library
ber, the complete name over all fields is unique worldwide,
sion layer, between 10 and a maximum of 30 nodes may be
test ECUs comprehensively after they have been integrat-
The CANoe Test Feature Set is made up of CAPL test mod-
and there are no overlaps.
connected to the network. J1939 provides uniform diagnos-
ed in the network structure. Consequently, weak points are
ules, XML test modules and .NET test modules. They are
Since addressability of the devices is inefficient in practice
tic access for service testers and on-board diagnostics. Legal
often not revealed until very late, unless one relies on the
able to cover all challenges arising in testing tasks of vary-
when 64 bit long device names are used, the SAE defines
requirements specify that a branch line with a length of up to
support of proven software tools right from the start.
ing complexity, from simple to difficult test cases. While
8-bit addresses for the individual vehicle components in the
5 m must be possible here, e.g. for road tests of the emis-
Given this situation, the use of specialized tools offers de-
the C-like script language CAPL is ideal for creating exten-
heavy-duty vehicle field; practically these addresses never
sions control system. Bridges can be used to extend J1939
velopers substantial simplifications in testing and diagnos-
sive test scenarios, the primary focus of XML is on simple
change over the life of the components. This does not apply
networks to include trailers/implements, enabling imple-
tic tasks. For many years now, Vector has been actively in-
parameterization of test patterns and simple generation
to the agricultural and marine industries; there the ad-
mentation of a separate network there (Figure 3). In the EU,
volved in SAE J1939 subcommittees and regularly partici-
of test procedures. That makes it possible to implement
dresses are dynamically negotiated at the start, based on
ISO 11992 has prevailed for this purpose, while in the USA
pates in working sessions. With a universal tool chain for all
application-specific test modules (function libraries) in
the device name. The addresses 0 to 127 are assigned to the
the “Power Line Carrier” is state-of-the-art technology.
J1939 projects, it is possible to efficiently solve the most
CAPL and then generate test control that is individually
challenging tasks in networking and communication in the
adapted to the ECU configuration. The J1939-specific ex-
most commonly used ECUs such as engine, transmission, retarder, brakes, etc., while the range from 128 to 247 is re-
Timing Requirements in ECU Design
heavy-duty vehicle field [1]. Besides development, testing
tensions in the Test Service Libraries allow the system re-
served for agricultural, marine, construction equipment,
In designing J1939 ECUs, care should be taken to ensure
and analysis tools, embedded software components tai-
act to Parameter Groups (PG) instead of typical CAN iden-
etc. Service tools, OBD scanners, etc. occupy addresses
that no messages are lost due to hardware or design limi
lored to the special requirements of J1939-based applica-
tifiers. They also offer test patterns for J1939 protocol
from 248 to 253. Finally, there are the special addresses:
tations. At a baudrate of 250 Kbps, transmission of one bit
tions are available, and customized project work and train-
functionality and checks (background monitoring) for proto
254 to identify devices that do not have their own address
takes 4 microseconds. With 8 data bytes, a typical mes-
ing events round out Vector’s products and services.
col violations. For example, it is possible to test whether the
and 255 that is used as a global address for addressing
sage length of about 128 bits is obtained, yielding a trans-
A J1939 extension is available for the widely used CANoe
ECU is able to send all Parameter Groups at the configured
broadcast messages.
mission time of about 500 microseconds per CAN mes-
development and test tool; it spares heavy-duty vehicle de-
cycle time under high bus load. Furthermore, it is possible to send faulty transmissions via the BAM (Broadcast
sage. The shortest message length, however, is 64 bits, i.e.
velopers from needing to train in the details of the J1939
Types of Communication: Point-to-Point or Broadcast
it must be possible to receive messages at intervals of 250
protocol. The package from Vector extends basic software
Announce Message) and CMDT (Connection Mode Data
The J1939 protocol supports two communication types:
microseconds and process them sufficiently fast. In prac-
functionality to cover all necessary protocol-specific fea-
Transfer) transport protocols for test purposes.
point-to-point transmissions (1:1) are directed to precisely
tice, this leads to a high interrupt load due to the CAN con-
one target address; they are used for device configuration
troller’s often limited CAN identifier filtering capabilities.
or ECU commands, for example. Broadcast messages (1:n),
Filtering also usually needs to be implemented in software.
Figure 3: With regard to network topology, J1939 enables flexible design of wire harnesses. Individual ECUs can be connected via branch lines up to 3 m in length. Bridges make it possible to realize separate networks on implements and trailers.
10/2
Figure 4: Tests conducted with the help of simulations during development make it possible to detect and correct errors early on in all development phases. The CANoe Test Feature Set offers extensive testing and analysis capabilities.
10/3
Networking Heavy-Duty Vehicles Based on SAE J1939
To create the test modules – besides the J1939 Test Module
Progressing through the various stages of the V develop-
Image rights:
Manager and the convenient Test Automation Editor – the
ment model, individual tests and subsystem tests are pos-
Vector Informatik GmbH
Option DiVa is useful. DiVa creates a connection between
sible through final verification of the overall system. This
CANoe and the diagnostic specification tool CANdelaStudio,
enables early detection and correction of errors. If an error
Internet links:
so that specifications created there can be ideally used in
is found, the automated tests can be restarted at any time;
[1] J1939 solutions from Vector – www.j1939-solutions.com
further ECU-specific diagnostic tests.
they minimize the risk of side effects in error correction. As
[2] Download of presentations from J1939 User Day –
Other functions of the Test Feature Set relate to test flow
a result, development is characterized by short verification
www.vector-worldwide.com/ud [most of them are German]
control and automatic report generation, including statisti-
cycles, enabling a seamless transition from MIL (Model in
cal information in XML or HTML format based to individual
the loop) to SIL (Software in the loop) and then to the real
requirements. Further options for automating test pro-
ECU (HIL – Hardware in the loop). If there are exceptional
cesses are enabled by the COM interface, e.g. options relat-
real-time requirements of the simulation platform, a spe-
ing to flow control, parameter changes or status queries.
cial real-time version is available with CANoe RT.
CANoe Option J1939 provides a trace window, J1939 diagnostic monitor and J1939 diagnostic memory access for
Realizing Goals quickly with standardized Embedded
diagnostic purposes. The diagnostic monitor supports
Software Components
various J1939 diagnostic messages, such as DM1 and DM2,
Use of CANbedded J1939 software components leads to
and it serves to display and clear active errors. Also possible
quick development results. These components largely re-
is access to memory areas, objects and parameters as well
lieve developers of the need to handle all of the details of
as periodic object updating for monitoring purposes.
the J1939 standard, and they avoid duplicated develop-
Peter Fellmeth studied at the University of Applied Sciences in Esslingen, Germany, majoring in Computer Engineering and specializing in Automation Technology. He is team leader and product manager at Vector Informatik GmbH, where he is responsible for the development of products and customer-specific projects related to J1939, ISOBUS, Ethernet and DeviceNet. Thomas Löffler studied Automation Technology at the University of Applied Sciences in Reutlingen, Germany. He has been employed at Vector Informatik GmbH since 2000, initially in the DeviceNet area, and since 2002 in the J1939 and ISOBUS area. His areas of specialization are configuration and generation tools for embedded software, support of customer projects and product and protocol training programs.
ments. A key aspect is a central OEM-managed database Integrating Matlab/Simulink Models in J1939 Network
containing all elementary information related to ECU com-
Simulations
munication. Depending on requirements, this information
Generally, various function models are created for mechani
might be distributed to other working partners, producing
cal components such as transmission, powertrain or even
flexible distribution of tasks between the OEM, network
the entire vehicle during the different heavy-duty vehicle
specialists from Vector and suppliers (Figure 6). The latter
development phases. ECU architectures are initially saved
can use the GENy configuration tool for specific settings
in virtual CANoe function models and are implemented
and parameterizations. The results are reduced cost and
step-by-step on the final target hardware platform.
timing for implementation and testing, compatibility on
CANoe .J1939 can also integrate Matlab/Simulink models
the CAN bus based on unambiguous signal interpretation
in ECU and network simulations (Figure 5). With the Real-
and maximum quality and flexibility in the J1939 communi-
Time Workshop from Mathworks the user generates a
cation stack. CANbedded J1939 supports all relevant mi-
*.DLL for CANoe so that variable names and units are
crocontrollers and is characterized by low ROM and RAM
compatible.
memory requirements as well as high runtime efficiency.
Figure 5: Not only is CANoe able to simulate functional models of ECUs during the development process and integrate models created with Matlab/Simulink in the scenarios; at the same time it also serves as a convenient user-interface. (Source: Renault Trucks)
10/4
Figure 6: Standard software components of the CANbedded J1939 package lead to quick development results without developers needing to be concerned with all details of the J1939 standard. A centrally managed database avoids duplicated developments and enables optimal work distribution.
10/5
vious 250 kbit “Type I” diagnostic plug. A “Type II” plug is
commercial vehicle field, but has never really been imple-
compatible with a “Type I” socket. Another change is that
mented or used before.
the “Type II” diagnostic socket defines pins previously used
In conjunction with Network Management, the newly added
for SAE J1708/J1587 as reserved. Consequently, a J1708/
Name Management should be mentioned for the sake of
J1587 network can no longer be addressed via a “Type II”
completeness. This is a standardized interface for changing
diagnostic plug.
specific components of the 64 bit device name. This might be necessary if the relevant function or measurement
SAE Gets Serious about Dynamics
parameter is derived from the device name. So, the device
Changes are also being made in the area of Network
name can be used to identify the position of an exhaust gas
Management [5]. For a long time now, the J1939 commit-
temperature sensor – upstream or downstream of the cata
tee has been deliberating over ways to handle the short
lytic converter, on the right or left side of a dual-flow exhaust
supply of permanently assigned ECU addresses. This is es-
system. Changes can be made to multiple ECUs in sequence
pecially problematic for manufacturers of sensors with a
and activated at a specific point in time. This could be help-
direct bus connection. The number of new devices is grow-
ful, for example, in a case where multiple ECUs of a net-
ing rapidly due to heightened exhaust emissions require-
work need to be assigned a new function simultaneously.
ments and the addition of assistance systems. Many alter-
These changes in Network Management are supported in
natives were proposed but then rejected. They ranged from
Version 7.5 of Vector’s CANalyzer .J1939 analysis tool and its
a dedicated network for sensors to implementation of a
CANoe .J1939 development and test tool.
new protocol – e.g. by using previously reserved data pages.
Quo Vadis SAE J1939 Standardization Due to new application layer requirements, SAE is continuing to develop the J1939 standard, which is primarily used to network powertrains in commercial vehicles. However, optimizations and extensions are being made in the other communication layers as well, right up to the physical transmission layer. This article summarizes the current state of discus-
Meanwhile, the fact was that SAE has not assigned any
AUTOSAR and J1939 Come Closer Together
more new addresses. That was an unsatisfactory situation
The introduction of AUTOSAR in the passenger car industry
for ECU suppliers. Often, they did not know whether their
is ramping up quickly. Yet, there is also interest in exploiting
product designs would have lasting value. In the latest ver-
the benefits of AUTOSAR in commercial vehicle and the agri-
sion of Network Management, SAE recommends imple-
cultural machine markets. However, the special requirements
menting “Address Arbitrary Capable” ECUs. These ECUs
of these markets have not been a focus in the development
are able to compute their own addresses based on the
of AUTOSAR. Therefore, the AUTOSAR versions released so
momentary vehicle configuration – and indeed at runtime.
far have very limited potential in these markets. In particu-
Essentially, this approach aims to utilize the mechanism of
lar, the requirements of SAE J1939 cannot be mapped to
dynamic address allocation that has always existed in the
the current AUTOSAR concept, or only in a very limited way.
sions within the SAE J1939 working committee, such as the planned introduction of the 500 kbit physical transmission layer and changes to network management. Moreover, it also explains ongoing efforts to standardize J1939 in AUTOSAR Release 4 and WWH-OBD diagnostics.
Based on the CAN bus (High-Speed CAN per ISO 11898),
transport layer is a long overdue step. European commer-
the SAE J1939 standard is used primarily to network the
cial vehicle producers in particular are seeking a final deci-
powertrain and chassis in commercial vehicles. The proto-
sion in the near future. The specification will be released in
col creates a uniform foundation for communication between the electronic ECUs and operates by the plug-and-
a separate document, J1939-14, and its key aspects are: >>Twice the baudrate, 500 kbit instead of 250 kbit
play principle. The J1939 standard is an active standard
>>Use of shielded and unshielded cable as defined in [2]
that currently consists of 19 documents (Figure 1). The responsible SAE subcommittees generally meet four times a
and [3] is still possible. >>Topology is essentially a bus that has branch lines with a
year to decide on changes and further developments. The
max. length of one meter. To connect diagnostic tools, a
current versions of the documents may be purchased either
branch line (from the diagnostic socket to the diagnostic
individually or together as a package in so-called “JPaks”
tool) with a length of 5 meters may sometimes be used. >>The bus is terminated at both ends with a characteristic
from the the SAE website [1].
impedance of 120 Ohm. Up to 30 nodes are possible. More Bandwidth
10/6
For years now, the maximum 250 kbit bandwidth specified
The specification for the diagnostic plug [4] was adapted
in the standard has forced commercial vehicle developers
to 500 kbit operation. In addition, a new “Type II” diagnos-
to work at the limits of performance [2]. From a communi-
tic socket is being used in the vehicle which has a green col-
cation perspective, development of the 500 kbit data
or coding, and its connector keying prevents use of the pre-
Figure 1: Status of SAE J1939 documents (status in September 2010)
10/7
Quo Vadis SAE J1939 Standardization
When all nodes of a J1939 network are known, and node addresses are already defined at the time of configuration, it is relatively easy to map J1939 PGs to AUTOSAR: In case of such a static network, the ECU addresses are fixed. Therefore source and destination addresses are fixed, and so it is possible to work with static identifiers. To transmit data that is longer than the 8 bytes available in a CAN frame, J1939-21 specifies two transport protocol (TP) variants. They are the Broadcast Announce Message (BAM) variant and Connection Mode Data Transfer (CMDT; also known as RTS/CTS) variant. Both of them are already defined in AUTOSAR Release 4.0 and have been available since December 2009. Therefore, AUTOSAR Release 4.0 already covers the require-
Figure 4: The WWH-OBD is specified in the six documents of ISO 27145.
Figure 5: On-board diagnostics in commercial vehicles is implemented by CAN-based protocols.
ments of many European commercial vehicle producers. More in-depth support of J1939 requirements is planned for
Figure 2: Layout of a 29-bit identifier in J1939 networks.
the end of 2012 in AUTOSAR Release 4.1. The target group
Commercial Vehicle Diagnostics Using WWH-OBD
also be possible which would enable access that is either
here includes European and some North American com-
On-board diagnostics (OBD) is a diagnostic system stand
wired over Ethernet or wireless.
mercial vehicle OEMs.
ardized by ISO; one of its applications is to monitor systems
Different than in the current OBD-II standard, WWH-OBD
The primary extended features being added to AUTOSAR: >>Support of multiple messages with the same layout (the
related to exhaust emissions control. Over the course of
only utilizes services already defined as ISO 14229 “Unified
time, regional standards were derived from this standard
Diagnostic Services” (UDS). No additional OBD-specific
same Parameter Group) >>Network management per SAE J1939/81 without dynamic
(e.g. ISO15031), which have now been merged again into
services are needed. Specifically, WWH-OBD requires sup-
WWH-OBD (World-Wide-Harmonized On-Board-Diagnostics).
port of the UDS services shown in the figure (Figure 6).
This standard was initiated by the United Nations and doc-
Effective at the beginning of 2014, all newly registered
the “dynamic” behavior of J1939. The AUTOSAR architec-
NM, i.e. without AAC (Arbitrary Address Capable) >>Responses to a request message
umented in its Global Technical Regulation 5 (GTR 5). ISO
heavy-duty commercial vehicles must conform to Euro VI
ture only allows fixed CAN identifiers, i.e. there is a fixed
>>Support for diagnostic services
27145 represents the technical implementation of GTR 5. It
standards, and so they must have WWH-OBD diagnostic
allocation between precisely one CAN identifier and one
>>On-board diagnostics (WWH-OBD) via J1939
establishes technical constraints for WWH-OBD. WWH-OBD
capability. Developments involving new types of vehicles
initially targets the commercial vehicle market, but eventu-
must fulfill standards one year earlier by 1-1-2013.
The “static” approach of AUTOSAR stands in contrast to
message layout. In contrast to this, a J1939 specific message layout is only allocated to a specific part of the identi-
Together with large European commercial vehicle OEMs
ally it should be extended to other vehicle industries as well.
UDS diagnostic services can be implemented with CANbedded
fier, known as the Parameter Group (PG). Some of the other
Vector actively participates in efforts to specify these
ISO 27145 consists of six parts (Figure 4). The current
communication software that also supports J1939, which is
components of the 29-bit identifier are dynamic and not
J1939 extensions for AUTOSAR. Today, Vector already of-
document status is a “Draft International Standard” (DIS),
available from Vector and is practice-proven in many pro-
defined at the time of configuration. Such a dynamic iden-
fers an AUTOSAR solution with a J1939 extension based on
and a final version is anticipated by the end of 2011. The
duction implementations. Recently, a production-ready
tifier can be modeled in AUTOSAR by creating a separate
AUTOSAR Release 4.0 (Figure 3). It will soon be used in pro-
first step was to establish requirements for emissions con-
AUTOSAR solution has also become available for imple-
static identifier for each combination of priority, source
duction at one large European commercial vehicle OEM.
trol and diagnostic communications. This involved specify-
menting WWH-OBD diagnostics via UDS.
address (SA) and destination address (DA) that can occur
The extension for AUTOSAR Release 4.1 is currently in the
ing the vehicle-side implementation, data access and OBD
The described developments in the J1939 field show how
in a network (Figure 2).
development stage.
data. At this time, regional authorities are still defining
the standard continues to be adapted to current require-
limit and threshold values; harmonization will not occur
ments on a regular basis. The transfer, extension and modi
until a later point in time.
fication of concepts from passenger car technology aim to
For on-board diagnostics in commercial vehicles, the two
make the development of J1939 ECUs more cost-effective.
CAN-based protocols “Diagnostics on CAN” (ISO 15765-4)
Vector, with its many years of networking expertise, is mak-
and J1939-73 are widely being used today (Figure 5). To
ing a contribution by actively participating in standardiza-
enable a cost-effective transition to WWH-OBD, diagnos-
tion committees. In turn, developers of commercial vehicle
tics over CAN will continue to be used at first. For the long
electronics benefit from early implementation of new stan-
term, diagnostics over the Internet Protocol (DoIP) should
dards in embedded software and development tools.
Figure 3: AUTOSAR basic software from Vector contains the two J1939 transport protocols BAM and CMDT.
10/8
Figure 6: The WWH-OBD uses these diagnostic services from the UDS.
10/9
Translation of a German publication in Elektronik automotive, 12/2010 Image rights: Vector Informatik GmbH Literature: [1] http://standards.sae.org [2] “CAN und offene Protokolle im Nutzfahrzeug“ [“CAN and Open Protocols in Commercial Vehicles”], Elektronik automotive 5/2005, page 60 [3] SAE, J1939-11, Physical Layer, 250K bits/s, Twisted Shielded Pair [4] SAE, J1939-15, Reduced Physical Layer, 250K bits/sec, Un-Shielded Twisted Pair (UTP) [5] SAE, J1939-13, Off-Board Diagnostic Connector [6] SAE, J1939-81, Network Management Links: Homepage Vector: www.vector.com Solutions for J1939: www.vector.com/j1939 Solutions for AUTOSAR: www.vector.com/autosar Product Information CANoe .J1939: www.vector.com/vi_canoe_j1939_en.html Product Information CANbedded J1939: www.vector.com/vi_canbedded_j1939_en.html Peter Fellmeth is Group Leader and Product Manager at Vector Informatik GmbH, where he is responsible for the development of products and customer-specific projects related to J1939, ISOBUS, Ethernet and Car2x. He is an active member of various working groups involved in the standardization of SAE J1939 and ISO 11783 (TC23/SC19/WG1). Holger Söhnle is Product Manager at Vector Informatik GmbH for Embedded Software in the area of J1939 and ISOBUS.
10/10
and they only use those properties actually needed in the
Vector CANtech [4] discussed the use of standard software
vehicle. A J1939 conformity test would be inadequate for
components versus in-house solutions. In particular, the use
these implementations – but the OEMs do not consider this
of off-the-shelf components offers a number of advantages
a disadvantage.
in areas that are not competition-relevant and are not typi cally core competencies. Purchased and in some cases
Reducing Development Costs with Standard Software
pre-certified components, such as the J1939 CAN commu-
Components
nication software or the operating system, lead to greater
The presentation by Ford [2] indicates that the network
assurance in the development process and increase inter
architecture is not viewed as a crucial competitive advan-
operability. Model-based development also contributes
tage. So, in this area it makes sense to use standardized
toward reducing sources of errors (Figure 1).
and largely generated software components. In its FNOS (Ford Network Operating System) initiative in the automo-
Optimizing J1939 Integration
tive area, for example, Ford took up the idea of making an
In its presentation, Navistar showed just how all US com-
implementation available to all of its suppliers. This re-
mercial vehicle OEMs might realize such savings potential
duced quality problems and their propagation to a mini-
[3]. In the context of its “Blue Diamond Program,” Navistar
mum. The commonality between this approach and J1939
acquired experience with both J1939 and FNOS. This involved
is that FNOS is like a standard for the suppliers. In contrast
marrying a Ford cab to a Navistar chassis. A gateway (Blue
to FNOS, however, many J1939 users implement the stand
Diamond Gateway) had to be developed that would act as
ard quite differently. Participants report that this situation
a link between the FNOS cab and the J1939 chassis. It be-
always leads to problems in integration. For example, mes-
came evident that the advantages of FNOS could not simply
sages might not be received, because sender and r eceiver
be transferred one-to-one to J1939, but that the underlying
priorities do not match, specific ECU addresses are as-
principles could. Navistar has identified a number of items
sumed or signals are not fully implemented. Navistar [3]
that could be improved for future J1939 integration: >>The communication description should be made with an
noted that even the exchange of information between
Integration of J1939 Systems in Practice Commercial vehicle producers are continually being confronted with problems in integrating networked systems with the J1939 protocol. Weaknesses include information exchange between OEM 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.
OEM and suppliers on which signals are available is a recur-
OEM-in dependent data format such as the DBC format.
ring source of errors due to outdated information and
This enables automatic detection of incompatibilities or
incomplete information. Instead of using an available quasi-standard – such as the DBC data format – to de-
missing signals (Figure 2). >>The OEM should have more influence in selecting the
scribe the CAN communication, text documents are often
number of communicated parameter groups and signals.
used.
This offers a better way to avoid or entirely eliminate
Ford’s experience with FNOS demonstrates that de-facto
potentially critical latency times or excessively high bus
compatibility increases the availability of products and significantly reduces integration effort. For OEMs, advantag-
loads. >>Suppliers can continue to write their own communica-
At the suggestion of key American truck manufacturers, the
OEMs. This means that the OEM in the US has less influ-
es are realized if they do not develop the reference imple-
tions software. A DBC database is used for improved
Vector US subsidiary hosted a conference to discuss improve-
ence on functionalities or the component manufacturer’s
mentation for different hardware platforms themselves.
knowledge transfer related to the communication
ment options for J1939 networking. At this conference, a
development processes. The role of the OEM is often limited
By outsourcing this work to a specialized company – in this
behavior and monitoring of communication.
number of presenters described their concepts and experi-
to that of an integrator.
case Vector – savings were attained on the order of about
ence in integrating J1939 components. In addition, weak-
In Europe, on the other hand, OEMs offer the vehicles in
800,000 US-dollars at Ford.
nesses were identified, and specific optimization potentials
different variants. Therefore, European customers do not
were discussed.
have the option of selecting components like their counterparts in the USA. European OEMs typically use their own
J1939 is not always J1939
10/12
chain of fixed suppliers who individually develop or inten-
The presentation by Vector showed how the SAE J1939 pro-
sively modify ECUs for them. The OEM specifies the entire
tocol takes on a different meaning in the USA, than it does
E/E design and sometimes the development process as well,
in Europe [1]. The market structures that have evolved and
and they are structured so that individual components can
the different technical requirements both play a role here.
be used in different model series or brands/markets. Stand
For example, the relationship between customer and OEM
ards or open protocols are only needed where external
differs; a US customer not only selects the vehicle functions
interfaces are provided, e.g. in emissions-related diagnos-
but the customer can also choose whether an installed
tics (OBD), fleet management (FMS), Toll Collect Modules
ECU – a brake ECU for example – comes from supplier A or
(OBU) or trailers (ISO11992). This is also the case when
B. Therefore, the E/E design and communication protocol
components, e.g. the engine, is supplied to other industries
used must be as flexible as possible and must be based on
such as agricultural or construction equipment. In practice,
standards. Typically, individual components are used across
European OEMs tend to view J1939 more as a “toolbox”
Figure 1: Development models in contrast (green, blue) and a potential merging (red).
Figure 2: Use of standard software components can reduce the share of application-specific software.
10/13
Figure 3: Shifting effort to the beginning of the development process reduces risks and integration effort.
>>Exchange of simulation models between OEM and suppliers
Image rights:
for all communication modules enables simulation and
Figures 0, 2 and 3: Vector Informatik GmbH
testing of the entire network.
Figure 1: Vector Informatik GmbH based on documents from Navistar [3]
Vector CANtech [5] has analyzed these items from a cost-benefit perspective and with regard to a timeline for
Literature:
their introduction. The use of a common existing data
[1] Fellmeth, P.; Vector Informatik GmbH: “E/E Develop-
exchange format between OEM and suppliers is highly
ment and J1939 in Europe, Overview about Current Status”.
recommended, since it requires little implementation ef-
JEIM Congress 2010.
fort, and the benefits are realized immediately. The use of
[2] Paton, E.; Ford Motor Company: “Ford Network Opera-
a conformity test offers additional advantages. It supports
tion System, The OEM Perspective.” JEIM Congress 2010.
the user at various points in the development process, e.g.
[3] Venkateswaran, S.; Navistar, Inc: “Blending Automotive
in implementation, verification and system integration, and
and Commercial Vehicle Network Technologies.” JEIM Con-
it improves both product quality and process effectiveness.
gress 2010.
Development tools such as Vector’s CANoe .J1939 support
[4] Stevens, S.; Vector CANtech, Inc.: “Evolution of Vehicle
automatic generation of conformity tests utilizing DBC
Embedded Software – COTs”. JEIM Congress 2010.
databases. This addresses critical paths in development
[5] Craig, J.; Vector CANtech, Inc: ”In-Vehicle Network
much earlier in the process, so that they do not first appear
Development, Best Practices”. JEIM Congress 2010.
in system integration (Figure 3). Links: Conclusion
Homepage Vector: www.vector.com
The conference showed that all of the US-OEMs in atten-
Product Information Vector’s solutions for J1939:
dance were working on the same problems, although at
www.vector.com/j1939
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 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. Translation of a German publication in Hanser automotive, 9/2010
10/14
Peter Fellmeth studied at the University of Applied Sciences in Esslingen, Germany, majoring in Computer Engineering and specializing in Automation Technology. He is group leader and product manager at Vector Informatik GmbH. At Vector, he is responsible for the development of products and customer-specific projects related to J1939, ISOBUS, Ethernet and Car2x.
295 kW (400 HP) and torques of up to 1,900 Nm. Two independent hydrostatic drive circuits without separate clutches are responsible for tractive power to the right and left sides. The engine controller delivers the required engine torque when starting up from a stop and prevents adverse events such as stalling. Simultaneously, load limit control offers protection against overloading and over revving of the diesel engine. A single gas pedal is used to accelerate and decelerate (braking), i.e. there is no working brake, only a parking brake. Changes in driving direction are achieved by differential track speeds. Each drive has infinitely variable output speed adjustment and its direction of rotation can be reFigure 1: Up to 620 PistenBullys are produced in Laupheim every year
versed. As a result, the fully electronic steering can support turning in place, pre-selection of driving direction and speed reduction. The “steering aggressiveness” varies with driving speed; the driver can adjust it to his or hers specific needs. This means that the driving speed can be changed by gas
use on mountains and snow, there are also PistenBully ver-
pedal or load limit control without affecting the turning ra-
sions without a loading platform, versions exclusively used
dius. Wheel sensors enable straight-line and uniform curve
to transport personnel, excavating versions and even ver-
control or asymmetrical steering characteristics for special
sions that can swim. Kässbohrer produces about 600 to
applications.
620 units per year, and the cost per vehicle lies between 80,000 and 340,000 euros.
CAN and J1939 under Extreme Duty Conditions Vehicle Electronics Guarantees Functionality in Cold, Ice and Snow Anyone who has participated in winter sports at one time or another is familiar with them: The slope groomers that tirelessly prepare the ski slopes and transport goods to mountain stations or injured persons safely down to the valley. They
Nothing Runs without Vehicle Electronics Electronics is or at least was often considered a necessary
Power for Driving, For Ski Lifts and Emergency Electrical
evil by conventional machine building companies. The Käss-
Generators
bohrer Company, whose origins are in the steel building in-
The vehicles are driven by engines from Mercedes-Benz
dustry, has come full circle in its perspective here. Without
with power ratings between 90 HP and 460 HP. The latest
electronics any meaningful interplay between complex ve-
PistenBully 600 has a standard 12.8 Liter engine delivering
hicle components would be inconceivable. Vehicle electron-
not only embody a special species of all-terrain track vehicle, they also deliver the experience of true high performance. Vehicle electronics play a decisive role in the incredible capabilities of these machines. Without electronics neither functionality nor safety nor any other significant innovations would be conceivable. This technical article offers insights into the vehicle technology, development process and development tools of the latest generation of PistenBully vehicles from the Kässbohrer Company.
In contrast to conventional off-road vehicles, the technical
factors. Safety as well as comfortable and fatigue-free
challenge for the PistenBully is to master the numerous ex-
steering and controls were therefore key aspects of the
treme situations encountered in cold, snow and nighttime
vehicle concept. Intelligent automatic functions support
operation. The machine, capable of moving in any direction
the driver and reduce the number of control interventions
on inclines up to 45°, covers an area of 96,000 m2/h with its
needed, so that the driver can concentrate on what is
multiflex tiller. This technology is standard equipment for
important.
duties up to 4,000 m above mean sea level and extreme
Impact and puncture resistant windshield glass protects
outside temperatures; the elevation capability of the polar
the driver from rock impacts, and a lighting system with a
version even reaches up to 6,000 m.
wide array of running lights, searchlights and working lights turn night into day. Automatic integration of a rear camera
10/16
Greatest Safety under Extreme Conditions
image in the cockpit display also provides optimal visibility
Slope grooming is often scheduled for evening and night-
when driving in reverse. To support grooming on steep in-
time hours, while there are no regular winter sports ac
clines the vehicles can be optionally equipped with elec-
tivities. If vehicle drivers are underway alone in a snow-
tro-hydraulic cable drums that carry 1,000 m of cable. A
storm or fog at high elevations or in Arctic regions, the reli-
special feature is free rotation of the drum, allowing the
ability and availability of the vehicles can be life preserving
vehicle to turn 360° as often as desired. Besides models for
Figure 2: Overview of CAN networks in the current PistenBully
10/17
CAN and J1939 under Extreme Duty Conditions
ics is ever present, from steering, control of the engine and
capable and short-circuit protected inputs/outputs, also
hydraulic system, conveniences of vehicle navigation and
houses other functionality such as central locking, RF re-
the control of implements, to functions for operational
mote control, lighting control and voltage converters for
data acquisition, telematics and GPS.
12 V. The full load capable unit supplies a summed continu-
Consistent and thorough networking of the vehicle by CAN
ous current of 640 A at 24 V and thereby achieves a switch-
(Controller Area Network) was a prerequisite for achieving
ing capacity of up to 15 kW. The “Central electronics” unit
a decentralized control structure. This made it possible to
has connections to all five CAN buses. In total there is need
rationally combine electronic and mechanical components
for just eight “actual” fuses; everything else has been im-
to make one control module. In comparison to earlier
plemented to be short-circuit protected and “self-healing”
PistenBully generations, decentralization has enabled sig-
without relays.
nificant reductions in wiring costs. Nearly all communication is routed over the two primary buses CAN1 and CAN2
Maneuvering Is Easy and Intuitive
(of a total of five CAN bus lines). While CAN3 is used for
Connected to the internal vehicle bus (CAN1) are the con-
external communications in fleet management, the CAN4
trols and display elements of the cockpit. In addition to the
and CAN5 systems are reserved for future functions not
ergonomic semi-circular steering wheel, also includes a
currently needed, and they are technically ready to imple-
multifunction display with touchscreen, round CAN instru-
ment them. Additionally, CAN is utilized for software up-
ments, a Terminal Control Center (TCC) integrated in the
dates, parameter configuration and in measurement sys-
arm rest and a joystick with programmable function buttons.
tems. Since all functions can currently be implemented
The multifunction display gives momentary information at
with CAN, the use of newer communication systems such
a glance on the most important operating states and on
as FlexRay, LIN or MOST is not currently under discussion.
driving speed, cable drum tension, engine data, etc. It of-
The electrical system is set up to be fully modular and is
fers intuitive control, on the touchscreen or via the TCC. The
uniform across all vehicle variants. Since the basic wiring
operating panel mounted to the right of the driver with its
already considers all current and future options, it is easy to
film keypad lets the user select numerous Pistenbully func-
accomplish expansions and retrofits by means of adapter
tions directly. A joystick is used to control the various move-
wire harnesses.
ments of the snow blade and of the rear implement carrier
Figure 4: CANoe as joystick simulator for testing hydraulic valves
as well as used to set the tilling pressure, cable drum tenLots of Power Electronics, just a Few Fuses and no Relays
sion, etc. The joystick is an in-house development, since
The PistenBully universal PSX control module is responsible
none of the commercially available models could satisfy the
for central control of all functions such as performance and
expectations of Pistenbully developers.
power management, engine control, hydraulics of the drive and tilling pumps, oil flow distribution of the working hy-
CAN Controls Hydraulic Module
draulics, front and rear, as well as monitoring of all sensors
CAN2 serves as a sensor-actuator bus for engine control
and actuators. It is supplemented by the “central electron-
and valve control and an interface for sensors. The hydrau-
ics” unit, which besides offering numerous diagnostically
lic valves are driven entirely via CAN, i.e. without supplemental analog or digital I/O signals. On the part of the sensor/actuator bus, so-called multi-modules provide input channels, digital outputs, PWM outputs and bridge outputs that are diagnostically capable, short-circuit protected and self-healing. The sensors connected here are all equipped with 4 to 20 mA current interfaces to automatically compensate for contact resistances when electrical connections corrode. While Kässbohrer utilizes its internal KGF protocol for the CAN1 functional bus, the J1939 protocol is used on CAN2 for the drive system. The advantage of standardized drive management based on SAE J1939 is that the drive system can be built with components from outside suppliers, independent of the vehicle producer, including a suitable diagnostic system. On the functional side, the proprietary proto
Figure 3: Controls and display components in the PistenBully cockpit
10/18
col was used intentionally to prevent unauthorized ma nipulations and simultaneously to protect know-how. That is why it was also decided not to use the CCP (CAN Calibra-
Figure 5: CANoe in flash mode
10/19
CAN and J1939 under Extreme Duty Conditions
tion Protocol) standard for the ECU application. The CAN
From Simulation to Real PistenBully Electronics
use this protocol to generate diagnostic and setup infor-
Comprehensive Vehicle Diagnostics on a Display Screen
bus systems can be parameterized and diagnosed from a
Software development and vehicle calibration covering all
mation in temperature tests, EMC tests and reaction tests
The vehicle can be fully parameterized at any time via a pro-
laptop.
control modules are all performed at the Kässbohrer Com-
of valve controls, for example, and this helps them to keep
gramming PC that is connected to the CAN diagnostic con-
pany. This lets the producer from Laupheim adapt flexibly
solutions for production vehicles lean.
nector. For every PistenBully there is an electronic vehicle
Safe Return to the Valley even if the Bus Fails
to new operating situations. Since the complexity of the
The development of dual-channel fan control in the Pisten-
record that seamlessly documents software updates, the
It is interesting that X-by-wire systems have already been
software and the electronic functions is constantly grow-
Bully was completed in an exceptionally short time without
life of individual components, current software levels, etc. It
used in PistenBully production vehicles since the 1970s,
ing, developers on a project like the PistenBully must rely on
utilizing real hydraulic pumps, valves or motors. In such cases
is possible to restore the delivered state at any time. If
while its implementation in general road vehicles was not
powerful tools for software development too. Over the
CANoe realistically simulates all necessary CAN nodes,
problems occur at the customer, On-Board Diagnostics of-
even a topic of discussion until decades later. Entirely dif-
course of the development process it is essential to per-
sensor signals and ECU information. In ECU setup CANoe
fers fast and convenient fault localization over the cockpit
ferent legal regulations apply to the operation and safety
form design functions, tests and simulations of subsystems
enables access to EEPROM contents via an in-house flash
display. All hydraulic functions, sensors and actuators are
of pure off-road vehicles not subject to highway vehicle
and overall systems. This is where CANoe with the J1939
protocol. This is easy to reprogram with the integrated pro-
designed to be electronically diagnosable. All that is needed
registration, since the vehicles are used exclusively on pri-
Option from Vector comes into play.
gramming language CAPL (Communication Access Pro-
for in-vehicle troubleshooting is a circuit diagram and the
vate land. If there is failure of the steering potentiometer,
CANoe’s capabilities as a development and simulation tool
gramming Language). The EEPROM data stored on the
display; no other equipment is needed. Stored in the fault
driving direction pushbuttons and/or the redundant gas
range from simulation of a single network node, to testing
hard drive can be loaded into the controller at any time.
memory are the error history and error frequencies.
pedal with a contact less sensor, driving capability is pre-
and diagnostics, to representation of complete CAN net-
served as long as possible. The vehicle, weighing in at be-
works. Beginning with initial studies on the purely virtual
Indispensable: Real-time Capability of Development Tools
Image rights:
tween 7 and 10 metric tons and capable of a maximum
model, the virtual nodes can gradually be replaced by real
An employee explains: “As developers we rely on good tools,
Kässbohrer Geländefahrzeug AG
speed of 23 km/h, can then be driven safely back to the
hardware step-by-step over the further course of develop-
and CANoe’s reliability is excellent! Real-time capability is
valley with emergency running characteristics at a throt-
ment. In this case, vehicle functions are executed by a virtual
especially important to us. We have already had negative
tled-down speed of 5 km/h. Even if both CAN buses fail the
ECU in an OSEK emulation. Among other things, this makes
experiences with similar software on another project. It
PistenBully remains maneuverable with control via PWM
it possible to control and display the states of virtual sen-
took days of troubleshooting to finally find out that the
signals.
sors and actuators. It is also possible to generate associat-
tool simply could not keep pace with our sampling rate re-
For the electronics, besides satisfying requirements for
ed control panels automatically.
quirements, and this led to erroneous results.”
harsh temperature and humidity conditions and mechani-
In-house user interfaces, panels and other tools that are
cal stresses, other special requirements also apply, e.g. with
Short Development Times
frequently needed are generally programmed in-house at
regard to electromagnetic compatibility. This ensures that
At Kässbohrer some of the uses of CANoe are to simulate
Kässbohrer using Borland C++. Even in such custom devel-
the high field strengths of radio transmitters on mountain
bus loads, function as a measurement tool and parameter-
opments CANoe databases always serve as the founda-
peaks will never impair vehicle functions.
ize ECUs by the proprietary KGF Protocol. The developers
tion. Moreover, CANoe facilitates optimal cooperation with
Thomas Böck (Graduate Engineer) studied general electrical engineering at the technical college in Kempten, Germany. He manages development in the electronics/ hydraulics area.
Peter Betz (Graduate Engineer) studied telecommunication engineering at the technical college in Ulm, Germany. He is responsible for system development in the electronics development area.
suppliers since the behavior of assemblies can be tested in advance. The PistenBully developers only regret that not all system suppliers provide CANoe simulations of their products or make them available early on.
Markus Hörmann (Graduate Engineer) studied telecommunication engineering at the technical college in Kempten, Germany. He manages test equipment construction in the electronics testing area.
Mobility for Fine Tuning on the Slopes Another important aspect is tool mobility. Since snow conditions are constantly changing, fine tuning of the drive system is often performed locally in the mountains. When it is important to perfect control loops for the various types
Lothar Felbinger (Graduate Engineer) studied automation engineering at the technical college in Reutlingen. Since then he has been working as Key Account and Business Development Manager at Vector Informatik GmbH for the Open Networking product line.
of slope preparations and adapt them to local conditions, CANoe operated on a laptop proves to be an efficient mobile diagnostic and measurement laboratory.
Figure 6: CANoe in measurement data acquisition during vehicle trials
10/20
Figure 7: Easy fault localization for the driver with OBD
10/21
it difficult to achieve universality of change requirements
There are also differences in the area of in-vehicle diagnos-
during development. Thus, a change would need to be
tics: In Europe, OBD diagnostics is implemented per UDS
made in different tool configurations without any auto-
(ISO15765), and in the USA per SAE J1939-73.
matic, inter-tool consistency check. This causes organiza-
Current Trends in Network Development for Heavy-Duty Vehicles Factors of Success in Electronic Development ECU networking in heavy-duty vehicles is characterized by the same challenges as in the automobile. Added difficulties are caused by the large numbers of variants with low production volumes and longer product life cycles, requiring a suitable architecture layout. Specially modified development methods are indispensable in handling cost pressure and sending reliable vehicles onto the street.
tional friction losses, especially in inter-departmental or
Attaining the Goal by Different Approaches
inter-site development projects.
The approach at MAN Nutzfahrzeuge AG is based on use of
Therefore, a database with authoring tools should stand at
an integrated development database known as the “Com-
the center of the tool chain. Both the database and author-
mon Engineering Data Backbone”. All vehicle-specific func-
ing tools need to be specifically adapted to the require-
tions are developed from this platform, and all vehicle-spe-
ments of the specific vehicle manufacturer. Besides purely
cific information is stored there. The eASEE Tool Suite from
technical aspects, the tools also take the individual devel-
Vector – with its 8 domains – serves as a universal develop-
opment process of the companies into account. Variants
ment database, and it was specially adapted to require-
management, configuration management and even the
ments at MAN in the framework of a configuration process
maintenance of workflows are represented in the tools. If
(Figure 1). It serves the needs of functional development
external suppliers need to be integrated in processes, the
and as a description of the communication matrix. Since
data exchange formats that are used may be standards or
MAN relies on the SAE J1939 standard as much as possible
de-facto industry standards such as the CANdb++ data
in communication, eASEE was adapted to the require-
format by Vector Informatik. In some cases, the vehicle
ments of the J1939 protocol.
manufacturer also prescribes the use of certain tools to its
A special module that was developed for MAN and adapted
suppliers. They are then tightly coupled to the database
to the Data Backbone serves as a bridge between model-
and support the supplier especially in such aspects as com-
ing in eASEE and automatic code generation for the ECUs
patibility to requirements, quality and efficiency. Examples
(Figure 2). In code generation, the Munich-based heavy-duty
would be code generators for embedded systems or test
vehicle producer relies on proven CANbedded J1939 stand
tools such as the CANoe .J1939 development and test tool
ard software components from Vector. CANbedded J1939
from Vector.
gets all of the information it needs for configuration and
System design is becoming increasingly complex due to
code generation directly from the database, and it can
growing requirements for networking. Individual ECUs are
enerate the embedded code without manual interventions. g
being installed on different platforms and different coun-
This enables immediate transfer of changes made in model-
tries, which increases the number of variants. This requires
ing to the ECU code. This process prevents errors such as in-
flexibility in communication structures and in mapping
correct configuration of the code generating tool and guar-
functions to ECUs. This not only affects the available si
antees error-free and complete code generation. This pro-
gnals, but also the use of communication protocols. In Eu-
cess also simplifies verification of the total system, since
rope, for example, proprietary communication protocols
sections of the software have already been checked. It is
are often used, which is similar to the situation in the auto-
possible to reuse the communication data for analysis tools
The number of ECUs, and hence the amount of software,
umes. Although simultaneous use of electronic ECUs over
motive industry there. In the North American market, how-
like CANalyzer .J1939 or test tools like CANoe .J1939 from
has multiplied since electronification began in the early
different brands and integration of standardized compo-
ever, the SAE J1939 protocol dominates for heavy trucks.
Vector, supporting the development of application layers.
1990s. While this primarily related to the engine controller
nents can reduce cost pressure, they make the design of
at the beginning, a large number of electronic “helpers” are
electronics and software more complex.
being implemented today. Examples include ABS, ESP, ACC
10/22
and other driver assistance systems that make highway
Flexible Solutions Are in Demand
traffic safer and driving more pleasant. Analyses [1] as-
When one considers the variety of strategies used by dif-
sume that their implementation will increase further, and
ferent heavy-duty vehicle manufacturers, it quickly be-
that electronic control modules will account for 90 % of all
comes clear that there is no universal solution. However,
innovations by the year 2010. A key aspect is that 80 % of
from a bird’s eye perspective clear trends can be seen, such
these innovations will exclusively involve software or the
as the use of standards, code generators and a universal
functions implemented in software. In this context, it is
tool chain. The number of ECUs is increasing at a rather
clear that software development methods play a crucial
moderate rate, while the number of functions implemented
role in the development process for the total vehicle, and
purely in software continues to grow rapidly.
they have a significant influence on a vehicle’s success or
Common to solution strategies is the use of a comprehen-
failure on the market.
sive and universal tool chain – from requirements to valida-
Compared to automobiles, heavy-duty vehicle manufac-
tion. The use of individual, non-coordinated tools proved to
turers are confronted by the special challenges of the rela-
be impractical in the past. The configuration processes and
tively large number of variants with significantly lower vol-
work results of individual tools are too different. This makes
Figure 1: The MAN Common Engineering Data Backbone
10/23
The Volvo Truck Corporation chose a strategy for software
Vector as its supplier of tools and embedded software
development that has now become established in the au-
components, since Vector already offers solutions in all
tomotive industry too: the use of AUTOSAR and its overly-
areas, and it was possible to adapt them to Volvo-specific
ing tools (Figure 3). The benefits of this approach lie in the
requirements very flexibly.
use of standardized and proven tools. They offer benefits in a development used intensively across brands that is dis-
Image rights:
tributed among many business sites. Common under-
Vector Informatik GmbH
standing of the underlying software structures and architecture is quickly achieved. It is easier to integrate suppli-
Literature references:
ers, and it is not absolutely necessary to specify tools. This
[1] J. Svensson, “The Use of AUTOSAR in Volvo Group”, pre-
reduces dependencies on individual tool producers and
sentation at Vector J1939 User Day; slides may be down-
suppliers.
loaded at: www.vector-informatik.de/j1939ud [most of
Problematic in this approach is the use of communication
them are German]
methods that are either incompatible with AUTOSAR properties or can only be used with it in a proprietary way. The use of J1939, in particular, should be mentioned in this context. While AUTOSAR essentially assumes a network of known nodes – and therefore a communication matrix that
Peter Fellmeth is a team leader and product manager at Vector Informatik GmbH, where he is responsible for the development of products and customer-specific projects related to J1939, ISOBUS, Ethernet and DeviceNet.
is known at the time of integration – this is decidedly not the case for J1939 with its plug-and-play concept. Volvo Trucks confronted this challenge with a two-prong approach. The first step was to identify which parts of J1939 were used in Volvo vehicles and integrate them in the existing Vector AUTOSAR tool chain. Secondly, Volvo – together with Vector and other European heavy-duty vehicle manufacturers – adopted portions of the J1939 protocol in AUTOSAR. This strategy lets Volvo exploit the advantages of AUTOSAR directly and universally. On the other hand, AUTOSAR integration of J1939 makes it possible to achieve
The reliable, efficient way to design and test networks
fundamental independence in tool selection. Volvo chose
Figure 2: Code for the ECUs is generated based on the description of the electronic structure in eASEE’s functional data management.
Solutions for Commercial Vehicles
Development processes for open networks in commercial vehicles can be implemented in the most costeffective approach with minimal time using specialized assistance: > Develop your network design in a systematic approach using reliable tools > Successfully implement software components for both proprietary and standardized J1939 and
Figure 3: When standardized data formats are chosen, standard products can be used to describe and create the ECU-specific software.
10/24
> Benefit from efficient configuration and extensive diagnostic, testing and analysis solutions Information and downloads: www.vector.com / j1939
AUTOSAR protocols The seamless interaction of Vector tools and Vector’s comprehensive services will improve the efficiency of your entire development process, from design to analysis.
Vector Informatik GmbH | Germany · Austria · Brazil · China · France · India · Italy · Japan · Korea · Sweden · UK · USA | www.vector.com
tified by conformity tests [2], different components, such
tended to enable quick and reliable localization of the error
as the Task Controller and implement, do not always har-
causes. This is especially advantageous if a network con-
monize in their interaction without problems. There is the
sists of components from different manufacturers. For ex-
potential for surprises in operation of an implement when
ample, the tractor manufacturer’s service technician can
the Virtual Terminal is used too. As well as for service tech-
use an ISO11783-12 compatible diagnostic tool to detect
nicians, in such a heterogeneous environment as the ISOBUS
problems related to an implement from a different manu-
it is difficult to definitively localize the cause of a problem
facturer. The technician might not be able to correct the
and correct it if necessary. Frequently, the technician is
problem, but can clearly identify its cause. If the cause lies
confronted with unfamiliar devices or combinations of de-
in the implement, the tractor manufacturer’s service tech-
vices. In view of these problems, and to assure customer
nician – who was summoned by mistake – can call up valu-
satisfaction, the manufacturer’s initiative AEF (Agricultur-
able information such as error codes or part numbers of
al Industry Electronics Foundation) set up a project group
the affected components to give the implement manufac-
tasked with conducting activities to improve the interoper-
turer’s service technician advance information on the prob-
ability of ISOBUS devices [3].
lem. This keeps downtimes to a minimum and leads to a higher level of customer acceptance of ISOBUS-equipped
Automatic Interoperability Tests for ISO11783 Systems Universal Test Solution Assures Compatibility The required “unlimited compatibility” of components on the ISOBUS cannot be attained by performing conformity tests at the end of device development alone. Rather, sound and continual tests over the entire development phase are neces-
Uniform Diagnostic Access for the Worst Case
machinery.
In the framework of standardization tasks, along with con-
Ongoing efforts to extend Part 12 of the ISO11783 draft
tinual efforts to refine and extend test cases of the con
standard are taking the direction of a standardized de-
formity test, Part 12 of the ISO11783 draft standard [4] was
scription format for diagnostics. This would let each manu-
written to create a common diagnostic interface. It is
facturer describe diagnostic contents individually for each
based on SAE J1939-73 diagnostics [5]. The section of Part
ECU. A prepared diagnostic application could use this de-
12 of the ISO standard that has already been published,
scription to diagnose the ECU regardless of which compa-
what is referred to as basic diagnostics, defines open diag-
ny manufactured it. The diagnostic description file might
nostic access. It provides basic functionalities and is in-
be downloaded from the ECU itself or over the Internet.
tended to enable a system overview. This includes unique
Manufacturers with their own company-specific diagnostic
identification of the ECUs on the bus as well as information
tool would integrate ISO11783 diagnostics into their exist-
on the software version, manufacturer’s part number and
ing tool. Manufacturers without their own custom tools
the conformity test performed. Each ECU can report mo-
could use future standardized diagnostic tools. One practi-
mentary errors, and when requested by the diagnostic tool
cal benefit is that a service technician would have sys-
it can also report previous errors. This information is in-
tem-wide diagnostic capability with just one tool. This en-
sary. Efficient use of such tests can only be achieved by using tools with domain knowledge that cover a large number of tasks ranging from simulation to analysis tests as well as conformity tests. Developers of implements and tractors need a tool that covers conformity testing, cycles through the tests independently, yet offer the freedom to only test certain sections and can be extended to test the application.
10/26
In the agricultural machinery field, the information age has
“One person’s pleasure is another’s pain” is common folk
long taken hold, and system thinking has replaced insular
wisdom. The situation is similar with the requirement for un-
solutions. As a result, a uniform data interface for intercon-
limited compatibility (system and manufacturer independ
necting the tractor, implements and on-board computer
ent) of ISO11783-compatible products [1]. For the customer
has become indispensable in agricultural equipment. In this
this is not only very easy to handle, it also opens up the
context, the internationally coordinated bus system ISOBUS
possibility of purchasing flexibility and independence from
was developed and introduced for the first time at the
the manufacturer. That in itself is a large motivational fac-
2001 Agritechnica fair. ISOBUS standardizes data commu-
tor in procuring such machinery. For manufacturers, howev-
nication between tractor, implements and farm manage-
er, this promise represents a great challenge in terms of
ment computers and enables system-wide data exchange.
development, operation and maintenance of the machines.
The ISO11783 series of standards consists of 14 sub-stand
CANoe .ISO11783 from Vector offers a universal develop-
ards; they each address different aspects of the technolo-
ment and testing solution here. Option ISO11783 for the
gy, ranging from System Description (Part 1), Physical Layer
CANoe tool provides the necessary domain knowledge and
(Part 2), Data Link Layer (Part 3), Network Layer (Part 4)
supports conformity to the ISO11783 standard (Figure 1).
and Virtual Terminal (Part 6), Diagnostics (Part 12) and File
Experience over the past two years in the ISOBUS field has
Server (Part 13).
shown that despite a sharply rising number of devices cer-
Figure 1: CANoe .ISO11783 can be used to utilize, analyze and simulate the complex communication structures of the ISOBUS standard easily and efficiently. Shown here is simulation of the File Server, two implements and the Virtual Terminal.
10/27
Automatic Interoperability Tests for ISO11783 Systems
ables efficient and reliable localization of the real causes of
impossible to use the conformity test during development,
to define frequently recurring tests and entire test se-
errors and ideally to correct them right away.
since 100 percent compatibility cannot be assumed at the
quences. The test sequences can be easily defined by XML,
beginning of development. Often just point checks of a cer-
for example. Figure 2 shows a schematic representation of
Automated Tests during the Development Phase
tain aspect are desired, e.g. a check of the Transport Proto-
the Test Feature Set. In such an environment, CANoe .ISO11783
Introduction of uniform diagnostic access helps to quickly
col. Such tests conducted over the course of development
may assume the role of the test master and link to or drive
identify a problem on-site and possibly replace the defec-
are generally performed very frequently, they have many
other tools over various interfaces such as COM or .NET. It
tive part. If there is some incompatibility, however, the situa
alternative test sequences, and they must be flexible in
is also possible to integrate CANoe .ISO11783 in an existing
tion is generally very different. Replacing the electronics
their configuration. Therefore, such tests should be de-
test environment via the same interfaces. Because of its
does not offer any help, since this does not correct the
signed for automation. If problems occur during the test,
extensive simulation and analysis capabilities, its use is not
cause of the problem. In such a case, corrected ECU soft-
extensive analytical capabilities are needed as well.
limited to just testing or simulation of individual ECUs. The tool can simulate entire networks (simulation of the re-
ware would be necessary. However, it would take time to produce and test this software. In addition, distribution of
One Tool for All Cases
maining bus). For example, operation of an implement
the modified software is often costly, since devices must be
CANoe .ISO11783 from Vector is a universal development
could be simulated via a Task Controller or the Virtual
recalled from the field. Suitable preventive actions can be
and test solution that is used to verify conformity to the
Terminal. With the help of Vector test hardware VT System,
taken to avoid such compatibility problems. One option is
ISO11783 standard, providing the necessary domain knowl-
CANoe .ISO11783 also directly drives real consumers such as
the conformity test mentioned in the introduction. How
edge [6]. The Virtual Terminal, for example, is a fixed com-
actuator motors and an ECU’s outputs, or reads in sensors
ever, a disadvantage here is that the application itself is
ponent of CANoe (Figure 1). Diagnostic messages can be
(Figure 3). CANoe .ISO11783 can be used to utilize, analyze
not part of the test. The focus in conformity testing is to
visualized using the Diagnostic Trouble Code Monitor and
and simulate the complex communication structures of the
test conformity to the standard. In addition, it is difficult or
Scanner. The integrated Test Feature Set makes it possible
ISOBUS standard easily and efficiently. It is a comprehensive, universal tool for verifying conformity over all product phases: from development to operation and service of the working machinery. Image rights: Vector Informatik GmbH Literature and links: [1] VDMA Professional Society for Agricultural Engineering: ISOBUS speaks all languages. Just speak along with it.2005, pg. 2 [2] VDMA Professional Society for Agricultural Engineering:
Figure 2: Phases of Test creation and interfaces with the CANoe .ISO11783 Test Feature Set: from creating the test sequence to evaluating the results.
ISOBUS-conformant devices per the ISO 11783 standard, www.isobus.net/isobus_E [3] www.aef-online.org/ [4] Society of Automotive Engineers: J1939 [5] International Organisation for Standardization: ISO/ FDIS 11783-12, ISO11898 [6] www.vector.com/isobus Peter Fellmeth studied Computer Engineering at the University of Applied Sciences at Esslingen, Germany, specializing in Automation Technology. He is a team leader and product manager at Vector Informatik GmbH, where he is responsible for development of products and customer-specific projects related to ISOBUS, SAE J1939, Ethernet and DeviceNet.
Figure 3: Used in tandem, CANoe .ISO11783 and the Vector VT System form a “Midsize HIL”.
10/28
10/29
forestry machines and public utility equipment as well as
can be activated or deactivated independently of one an-
machines for lawn, property and golf course maintenance.
other. Since all activities are logged, movements of the
In addition to its German subsidiaries in Zweibrücken, Mann
tractor during which the implement either protrudes be-
heim and Bruchsal, the American agricultural machine spe-
yond field boundaries or overlaps already covered areas
cialist opened another business site in Kaisers lautern in
result in automatic deactivation of the relevant sections.
early 2010. Employees in the new European Technology and Innovation Center (ETIC) work on future technologies and
The Task Controller as an Interface to Device Control
bring associated products to production maturity together
These and other functions mean that the tractor elec
with development departments at other sites. Precision
tronics must have a precise knowledge of the implement’s
farming, the integration of intelligent technologies in ma-
technical data and functions. The ISOBUS operator’s ter-
chines and agricultural electronics, represents a focal point
minal, as a part of the tractor electronics, is, in many cases,
of work at Kaiserslautern.
not just a user control and display system, but a minicomputer on which multiple applications run simultaneously.
Forging New Pathways in Testing ISOBUS Task Controllers Simulations Replace Inflexible and Time-intensive Test Methods
10/30
From Farm Computer to Automatic Section Control in
Such an application is the Task Controller, which is de-
Implements
scribed in ISO 11783 Part 10. Ideally, it simultaneously serves
The concept of Precision Farming illustrates current trends
as a documentation and control system with an interface
in agricultural technology and puts them in focus. The goal
to the Farm Management System via the TaskData.xml
here is to attain the greatest possible yield and maximum
file. In the John Deere GreenStar 2630 display, the Task
economy by optimal use of all available resources such as
Controller represents an interface between the John Deere
machines, seed stock, fertilizers, fuel, time, etc. The farmer
documentation system and an ISOBUS implement. The
takes the parameters of the planned field operations on
first time it is connected, the Task Controller loads a
the farm computer and uploads them to the operator’s ter-
“Device Description File” from the implement’s job com-
minal in the tractor by memory card or USB stick, or in the
puter. This device description file generally contains all
future via WLAN.
information necessary for the Task Controller, such as the
Telematics and satellite navigation also make important
implement’s working width, type of mount to the tractor
The inter-system and inter-OEM compatibility of ISOBUS-conformant devices lets farmers interconnect tractors and
contributions in combination with steering and track guid-
and number of switchable sections with associated ele-
implements from different manufacturers in any desired combinations. As easy as this may seem from the user’s
ance systems as well as section control. The result is seam-
ment numbers, if it is an implement with section control.
perspective, the level of effort required in the device development side is high, especially in the testing phase. A look at
less application of seed stock and fertilizers without any
The implement can be operated via the tractor’s operator’s
John Deere shows that conventional industry methods for testing electronic components are now often running into
areas of faulty application. At the same time, the technol
terminal (Figure 1).
their limits. An incomparably faster and more efficient means for attaining the desired goal is automatic test sequences
ogy provides for minimal overlaps on wedge-shaped fields
The Task Controller must seamlessly master the entire
with a simulated implement environment.
and saves raw materials at field borders. Implements with
bandwidth of possible implement device configurations.
section control are subdivided into multiple sections, which
Only then is it assured that the ISOBUS operator’s terminal
The tractor is a truly multi-talented field machine due to its
ISOBUS Compatibility and Conformity are Top Priority
ability to interact with many different implements. As long
The ISOBUS application plays a key role here. ISOBUS was
as the tractor remains a machine that offers pure pulling
created so that tractors, implements and operator termi-
and power take-off functions, and no other interaction
nals could communicate with one another and exchange
occurs with the implement, operation of the two devices is
data. The technical details are defined in the ISO 11783
relatively uncomplicated, but it is not very efficient due the
series of standards, and they cover all topics from the ISO
lack of an additional interface. Nonetheless, modern agri-
reference model to diagnostics to the file server. To ensure
culture requires intelligent, automated solutions, which
smooth interoperability of devices from different manufac-
support such functions as variable spread quantities for
turers, extensive tests are indispensible for both tractor
seeds and documentation of the work performed on the
and implement producers. Along with the obligatory con-
field.
formity tests, development departments must play through
Yet, as complexity grows and more intelligent functions
numerous other test scenarios. In addition, manufacturers
continue to make in-roads into agricultural technology, this
regularly organize “Plug Fests” where they verify that their
increases the effort needed to keep operation and handling
product functions are field-ready in their interactions with
as simple for the farmer as it was before. Long, drawn out
the products from other manufacturers.
start-up processes are counter-productive, not least in terms
One of the forerunners of modern agricultural technology
of customer acceptance of modern agricultural technology.
is John Deere, a company with a long tradition. Its products
It must be possible to rapidly and smoothly connect any of
range from tractors to field sprayers and balers to seeding,
a wide variety of implements to the tractor and have the
harvesting and chaffcutter machines. Not only does it develop
tractor’s electronics ‘understand’ it immediately.
agricultural machines, but also construction machines,
Figure 1: John Deere ISOBUS operator’s terminal with the Kverneland fertilizer spreader operating interface
10/31
Forging New Pathways in Testing ISOBUS Task Controllers
and simulation tool from Vector that was precisely tailored
The flexibility of the simulations offers considerable relief
passed-down development and test methods. Taking their
conceivable ISOBUS implement on the market. However,
to ISOBUS requirements. CANoe .ISO11783 assures ISOBUS
to John Deere, as is illustrated by the example of section
place are development, test and simulation tools such as
every work machine operates differently than another and
conformity in developments: from the initial phases of
control: simulations make it possible to vary the type and
CANoe .ISO11783, which provide for the greatest possible
uses a different combination of Task Controller functions.
product development to the test phase and maintenance.
sizes of working machines with little added effort, e.g. to
compatibility to the standard in all product phases. The
For test purposes, producers therefore exchange special
The complex ISOBUS communication structures can be
check whether the Task Controller could handle 16 instead
tool’s multibus capability enables troublefree display and
hardware boxes, in which the electronic functionality of
analyzed, visualized and prepared in a wide variety of ways.
of 8 sections. Implements can also be defined whose sec-
interpretation of ISOBUS and J1939 messages in a Trace
their implement product is represented. To the chagrin of
Functions such as the “Virtual Terminal” and “Interactive
tions are not strictly adjacent, but instead are offset in
Window. Since the tool covers the full range of ISOBUS
test engineers, aside from the ECU hardware and software
Task Controller” simplify working with ISO 11783 for the
back of one another. Since CANoe .ISO11783 represents the
functionality and is always at the latest revision level, John
contained in the boxes, they very seldom included all of the
developer. For example, the CANoe Terminal – unlike a real
standard comprehensively and completely, the agricultural
Deere attains better test coverage at lower expense in
components needed to conduct a comprehensive function-
terminal – can be used to simulate different display types,
specialist attained a higher level of test coverage in a
terms of time and personnel. At the same time, the agricul-
al test of the device logic.
resolutions or black/white settings. The “Interactive Task
shorter amount of time. This was especially true in applica-
tural machine specialist not only has the ability to test ex-
Controller” lets users load a device description from any
tion situations that are either unsupported or just partially
tended Task Controller functions, but to also simulate the
Seeking a More Efficient Test Method
real ISOBUS machine, or it can be used to verify simulators
supported by the hardware boxes. Such situations include
counterpart device at any time, for the latest and future
In Kaiserslautern as well, employees were using test boxes
before they are used for testing.
tests intelligent control of driving speed, checking for correct
developments of the ISOBUS standard.
handshakes or simulation of errors, e.g. when an imple-
Interesting in this context is the ISOBUS Multiple Product
and its applications will work properly together with any
and real devices of various implement producers to test the functionality and compatibility of their Task Controller.
Greater Test Coverage in a Shorter Time
ment does not signal its readiness for section control.
Implement Simulator (Figure 3). A multiple-product imple-
Considering the large number of field implements and out-
To preserve their independence from implement producers
At John Deere’s Technology and Innovation Center,
ment might be a corn sowing machine with under-root fer-
side companies, this is a very tedious and time-consuming
in testing the Task Controller, test engineers at John Deere
CANoe .ISO11783 not only serves to simulate externally
tilization. It enables simultaneous sowing and spreading of
process. Theoretically, it would be necessary to test every
especially make use of the tool’s simulation capabilities
produced work machines; it is also used for the company’s
solid fertilizer. One of the benefits, besides time savings, is
ISOBUS machine, whether designed for seeding or plant-
(Figure 2). Not only can CANoe simulate individual ECUs, it
in-house development of ECUs. In testing, either the real trac-
reduced soil erosion, because the tractor only drives across
ing, every fertilizer, every plant chemical sprayer and all
can also simulate entire networks. Developments can only
tor hardware can be used, or it too can be simulated. Since
the field once instead of multiple times. At the time of test-
other machines with every Task Controller version. In addi-
be tested reasonably and realistically if the later environ-
there are sometimes multiple versions of a Task Controller,
ing in early 2011, there was still no implement producer that
tion, the test boxes are not standardized with regard to
ment is either entirely present or is generated by rest-of-
each needing to be tested, users can quickly toggle between
offered such ISOBUS machines on the market. Therefore, it
their layout or handling. Each company follows a different
bus simulation. In the case of the Task Controller, in a wide
different variants to run. CANoe offers another advantage in
was only possible to have the Task Controller support such
operating philosophy, and some boxes are pure simulations,
variety of implement variants can be simulated. For exam-
distributed development tasks at different company sites. The
machines in a simulation. The full potential of simulations
while others largely match the real electronics. Before test
ple, John Deere can act entirely independent of external
simulation configurations can quickly and conveniently be ex-
has hardly been exhausted by the basic in-house applica-
personnel can actually perform their work, they must first
manufacturers, and it no longer needs to rely on the physi-
changed between different departments or even sent to col-
tion. From the perspective of John Deere employees, it
study many different user manuals to gain familiarity with
cal hardware boxes. A valuable tool for defining automated
leagues in the USA via the company’s intranet or by e-mail.
would be desirable if manufacturers would exchange their
numerous virtual control elements and functions.
and recurring tests is CANoe’s integrated “Test Feature
This approach, which is indeed typical in the industry but is
Set”. The system can act as either the Test Master or be
Covering Future Requirements
difficult-to-reproduce black boxes. The fear that this would
highly inflexible and unsatisfactory, motivated John Deere
inserted into existing test environments. Interfaces such as
It is no longer reasonable to expect that the complexity of
somehow reveal internal know-how is unfounded, since it is
to seek out a more efficient test method. Test engineers
COM or .NET are available for control and communication
the ISOBUS and the variety of implements available on the
easy to share the compiled simulations without the source,
found the solution in CANoe .ISO11783, a development, test
with other tools.
market today can continue to be mastered with old,
thereby preserving internal know-how.
Figure 2: Simulation of tractor and fertilizer spreader in CANoe .ISO11783.
10/32
CANoe simulations instead of the inflexible, expensive and
Figure 3: Support of an ISOBUS Multiple Product Implement by the Task Controller via a simulation
10/33
Translation of a German publication in Elektronik automotive, 11/2011 Image rights: John Deere Links: Homepage John Deere: www.deere.com Homepage Vector: www.vector.com Product Information CANoe .ISO11783: www.vector.com/ canoe.iso11783 Alexander Ostermüller, John Deere is a test engineer at John Deer’s European Technology and Innovations Center (ETIC) in Kaiserslautern.
Peter Fellmeth, Vector is a group leader and product manager at Vector Informatik GmbH. He is responsible for the development of products and customer-specific projects in the ISOBUS, J1939, Ethernet and Car2x areas. He is an active member of various standardization working committees for ISO 11783 (TC23/SC19/WG1) and SAE J1939.
10/34
plexity need time in the prototype phase before they attain
(RT target) with extensive I/O interfaces and a PC with the
the required maturity level. There is no way to avoid con-
CANoe .ISO11783 development, testing and simulation tool
ducting intensive and extensive conformity tests [1]. That is
from the company Vector, which is precisely tailored to
also why the various manufacturers meet regularly at so-
ISOBUS requirements. CANoe .ISO11783 provides ISOBUS
called “Plug-Fests” where they test individual devices for
functionality for developments from the design phase to
their compatibility with one another.
the testing phase and then maintenance. The complex ISOBUS communication structures can be analyzed, visual-
Better Test Quality by Automation Automated HIL Test System Ensures ISOBUS Functionality of Agricultural Machines The ISOBUS communication protocol has now essentially made it possible to use agricultural machines from different manufacturers together – for the most part without any problems. However, this accomplishment is associated with enormous development and testing effort by the manufacturer. The agricultural equipment manufacturer AGCO/Fendt
Test Setup of the Entire Tractor Network with an
ized and conditioned in many different ways. The room for
HIL System
interpretation of the standard mentioned above can be
The AGCO Corporation is one of the world’s largest manu-
handled in a greatly simplified way, because the tool essen-
facturers and distributors of tractors and agricultural
tially embodies the standard as interpreted knowledge.
machines. In 1997, the US-based agricultural machinery
The tractor breadboard fixture incorporates all electrical
corporation acquired the tractor manufacturer Xaver
and electronic tractor components such as ECUs, bus sys-
Fendt GmbH & Co. with headquarters in Markt-oberdorf,
tems, wiring, lamps, switches and controls. They are mount-
Germany, where it conducted its development production
ed in a space-saving way on a frame with industrial-format
and sales of tractors. Along with tractors, the company’s
racks, which is suitable for the laboratory. The fixture
lineup includes field choppers, combine harvesters and bal-
matches a production tractor fully; all it lacks are the diesel
ing presses products which are handled by the company’s
engine, transmission, body and add-on parts (Figure 1).
business sites in Bavaria, Sachsen-Anhalt and Italy.
The breadboard fixture is connected to the RT server’s I/O
To overcome the challenge of increasing testing effort,
routing block via a multicore cable (Figure 2). The server simu-
AGCO/Fendt conducts extensive tests on real tractor
lates various ECUs and the missing environment of the engine
prototypes. For some time now, the company has also been
and sensor signals in real time via MATLAB/Simulink; it sup-
working with the development and consulting company
plies such signals as speeds, rotational speeds and tempera-
Gigatronik. AGCO/Fendt develops nearly all of its ECU
tures. User-initiated events such as button presses or move-
software in-house, but it outsources some testing-related
ments of a joystick must be performed manually. A look at the
jobs to specialists in electronics and information technol
I/O level illustrates the magnitude and complexity of the over-
ogy. Its central tasks are to test Universal Terminals, Tractor
all HIL system. It consists of several hundred voltage and current
Controllers and to validate ISOBUS conformity.
interfaces, countless digital inputs and outputs, and outputs for
The key components of the test setup used at AGCO/Fendt
driving relays. In addition, there are frequency outputs, all sorts
are a breadboard fixture of the tractor network, a hard-
of CAN buses, a UDP interface and multiple voltage outputs
ware-in-the-loop system (HIL system), a real-time server
with supply voltages for the ECUs of the breadboard fixture.
used the CANoe .ISO11783 simulation and test tool to assist in integrating high-performance test automation in its existing hardware-in-the-loop test environment. Systematic tests now improve product quality, and in an era of ‘precision farming’ it lets the company confidently address the trend towards further intelligent vehicle components.
The J1939-based ISO standard 11783 describes CAN-based
Advantages of Standardized Agricultural Technology
communication in open networks for use in mobile machines
The advantages that ISOBUS provides to users and manu-
in the agricultural industry. ISO 11783 is a multi-master net-
facturers alike can be illustrated based on the example of
work based on CAN, whose protocol is harmonized with
the Universal Terminal (UT). After an implement has been
J1939. The ISOBUS concept describes a minimum degree of
attached, the UT reads a library with graphic control ele-
functionality for software and hardware that ECUs or net-
ments (Object Pool) from the implement’s controller. These
works must provide. The ISOBUS protocol ensures that a
objects represent the various functionalities available to
suitable add-on implement such as a field chopper or
the user and enable convenient operation of the implement.
manure spreader can be operated with any ISOBUS-conformant tractor and that its full functionality will always
Goal of ISOBUS Functionality Only Attainable with
be available on the tractor’s operating console. The individ-
Extensive Tests
ual parts of the standard, address such topics as Network
Until everything functions as smoothly as in the example,
Management, Tractor ECU, Universal Terminal (previously:
numerous test runs and correction cycles must be per-
Virtual Terminal), Task Controller, Diagnostic Services and
formed by the testing and development departments. On
File Server.
the one hand, the ISOBUS standard leaves some room for interpretation in certain aspects, but projects of this com-
10/36
Figure 1: The breadboard fixture of the tractor contains all electronic components of the real tractor model. Automated tests can be executed to real-time conditions with CANoe .ISO11783 and the RT target.
10/37
Better Test Quality by Automation
Test Automation is at Top of the Wish List
CANoe Bridges Gap to Real-Time Target
matically executes the same actions (Figure 4). The behav-
Another tool available for tests is a PC with CANoe .ISO11783
However, the test method practiced in this way was still
Before test automation could be successfully implemented,
ior of the simulated component in the individual test cases
simulation and testing software. The system is primarily
unsatisfactory for Gigatronik and Fendt. Highly qualified
it was necessary to answer the question of how the CANoe
is defined precisely in CAPL test modules. The test user in-
used for remaining bus simulation [2] and is capable of simu
employees were overworked by simple yet time-intensive
tests and simulations would be linked to the real-time tar-
terface also makes it possible to start the (virtual) engine,
lating individual network nodes up to entire sub-networks.
user actions. And despite the large amount of time re-
get in the HIL system. That is because a fast communica-
and sequences can be programmed for forward driving and
In CANoe .ISO11783, entire implements can be simulated,
quired, the tests still exhibited a somewhat rudimentary
tion channel is indispensable between the two systems. The
backward compatibility. Especially important is that, in
and the simulated implements are used to put the tractor’s
character considering the many parameters. Therefore,
RT target has a UDP interface with a data link protocol cre-
contrast to manual operation, CANoe.ISO11783 can exe-
ISOBUS capabilities to the test. Even sub-areas, such as a
managers began to seek out and evaluate options for sys-
ated by Fendt for sending information to the RT target or
cute tests with absolute reproducibility. In addition, errors
UT, can be simulated and displayed with all of their func-
tematic and in-depth test automation to replace the un
obtaining information from it. Therefore, Gigatronik devel-
may be interspersed in a controlled way. During the test
tions on a PC screen using CANoe. Testing of ISOBUS appli-
desirable manual interaction. A solution with robots that
oped a compatible counterpart to the CANoe side with its
runs, the test system logs all relevant messages and s ignals,
cations takes a lot of time and effort, because conformity
could simulate the human movements with mechanically
resources – in the framework of a student’s senior thesis.
and afterwards it automatically generates a test report.
must be verified for all parts of the ISOBUS standard used
actuated control arms would not only be extremely difficult
The test system can now control the RT server via UDP and
in the tractor implement. This also involves internal tractor
to implement; it would also be inflexible. So this solution
optionally transfer to it the same signal vector that was
Decidedly Greater Test Quality by Automation
communication. Moreover, the ISOBUS standard itself is
was rejected early on.
previously made by manual interaction with a real compo-
The automated test runs open up entirely new aspects of
available in various implementation levels. Therefore, it is
An electronic approach seemed more appropriate and
nent, e.g. an armrest with integrated controls (Figure 3). In
quality in ECU testing. It is easy to run tests overnight or
not sufficient to simply test to the current level, rather the
appealing, especially since a high-performance test tool
principle, any real, manually operated component can be
over several days, without employees having to be con-
test must also assure backward compatibility to a number
already existed in the form of CANoe. The ‘Test Feature
automated in this way. In the example, it was an intelligent
stantly present. Naturally, this makes it possible to go into
of previous implementation levels of implements. Finally,
Set’ integrated in the software produced a comprehensive
armrest; in another case it might be a steering wheel.
much greater depth, test much more, and systematically
numerous individual tests (test cases) must be run for
tool chain covering all phases: from defining test require-
Now that these preparatory tasks have been completed,
run through many more test cases. They include tests that
many different variants.
ments to executing tests and finally generating evaluation
Gigatronik and AGCO/Fendt have the capability of com-
would not have even been possible without the test tool,
Despite the availability of the described HIL system, em-
reports. CANoe can act as a test master, or it can be inserted
prehensively automating ISOBUS and ECU tests and
such as multiple repeated checks of bus loads, when the
ployees at Fendt and Gigatronik still needed to perform
in test environments. Interfaces such as COM or .NET are
quickly modifying them. In particular, the capabilities of
tractor drives off, when it stops, when multiple implements
some necessary tests by conventional manual methods.
available for drive control and communication with other
CANoe .ISO11783 now contribute towards much more effi-
simultaneously lift an object, etc. The developer analyzes
Specifically, this sometimes meant – depending on the test
tools. Nodes referred to as test nodes can be created for
cient test execution. For example, the UT provided by
how other messages react in these situations and how tim-
case – that an employee sat in the tractor and executed
the tests; they participate very normally in real bus events,
CANoe makes it possible to control an ISOBUS implement
ing values and cycle times behave. Statistical evaluations
specific tractor and implement operating functions repeat-
similar to simulated network nodes. Test engineers define
just as well as with the real UT on the tractor. While an em-
can also be performed, e.g. by starting the test run thou-
edly, for hours at a time and over several days. During such
their behavior and functionality in test modules, using either
ployee would have to execute user control functions for
sands of times and logging while varying such parameters
testing, the test system logged all user actions, system
the C-like script language CAPL or the XML standard.
hours on end at the real tractor armrest previously, now a
as the latency times of certain messages or examining
simulated armrest with the same integrated controls auto-
which effects might result when starting up the network.
Manual Testing as Time-Consuming Emergency Solution
reactions and the bus traffic. The logging record was then used to precisely analyze the contents of messages, terminal reactions, timing values, cycle times, etc.
Figure 2: The original HIL system is composed of the real-time target, tractor breadboard fixture and UDP interface for communication with a remaining bus system. The armrest with integrated user controls is implemented as a real component, for example, and must therefore be operated manually.
10/38
Figure 3: Integration of the CANoe interface in the existing overall system: The test module controls the existing test environment. The armrest, with its integrated controls, is implemented as a virtual component in the test system and can therefore be operated either manually or automated by the test program.
Figure 4: Instead of using a real armrest with integrated user controls, the signals coming from this component are fully implemented by a GUI that can be switched between manual operation and control by the test program.
10/39
Finally, one significant part of EDCU tests is to subject the
out programming expertise. Automobil Elektronik. Issue
system under test to errors. Here too, the RT target gener-
03.2012. pp. 58 – 60.
ates all conceivable error situations upon instruction by CANoe.
Links:
Bernhard Stöckl, manager for the responsible testing depart-
Website AGCO/Fendt: www.agcocorp.com
ment at AGCO/Fendt, is pleased: “Before, we had no test
Website Gigatronik: www.gigatronik.com
automation in the ISOBUS area. Previously, we conducted
Website Vector: www.vector.com
all of our work directly on prototypes which are not always
Product Information CANoe .ISO11783: www.vector.com/
available. We actually sat by the machine and operated the
canoe.iso11783
switches. Now, test automation offers tremendous relief in terms of workload. We require much less time on the real prototypes and no longer need to build so many extremely expensive test vehicles. At the same time, we saved a lot of time, which the developers are now investing in further
Bernhard Stöckl graduated in Mechanical Engineering from the Technical University of Munich. He is currently employed as Business Unit Manager for Testing of Drive Technology and Electrical/ Electronics at AGCO/Fendt. He previously started up the Hardware-in-the-Loop unit at the company as a test engineer.
automation efforts.” Outlook ‘Test automation’ is the magic word for mastering the constant growth in testing effort, simultaneously improving quality and saving on time and costs. AGCO/Fendt and Gigatronik have shown the capabilities offered by test automation with the CANoe simulation and test system and how to achieve efficient test practice quickly and in an uncomplicated way. The flexibility of the test platform makes it possible to overcome even greater challenges related to communication and interfaces in the process of integrating a large HIL system. Only by taking new approaches to integration tests can product quality be assured into the future. This issue is assuming increasing urgency in view of the further increasing diversity of ISOBUS-capable agricultural machines. Additional requirements will soon appear in the context of precision farming. More and more GPS applications that support work with field machinery will be implemented in both tractors and implements. In Tractor Implement Management (TIM), the implement controls the tractor, e.g. by specifying tractor speed or rpm. These extensions can be accomplished much more efficiently with test automation. Translation of a German publication in Elektronik automotive, 12/2013 Image rights: Lead Figure: Fendt Figure 1 – 4 : Gigatronik Literature: [1] Ostermüller, A., Fellmeth, P.: Forging New Pathways in Testing ISOBUS Task Controllers – Simulations replace inflexible and time-intensive test methods. Elektronik automotive. Issue 11.2011. pp. 32 – 35. [2] Albrecht, S., Decker, P.: Quick paths to a comprehensive remaining bus simulation – Create virtual networks with-
10/40
Hans-Werner Schaal graduated in Information Technology at the University of Stuttgart, and in Electrical & Computer Engineering at Oregon State University in Oregon, USA. He is Business Development Manager at Vector for open CAN protocols such as ISO 11783 and J1939 and in the IP and Car2x area. Previously, he was employed as a development engineer, project leader and product manager in the test tools area. Thomas Bückle graduated in Information Technology at the Polytechnical College of Ulm. He is Business Manager for the area of agricultural technology and construction equipment and Department Head for Embedded Systems Development at GIGATRONIK Technologies. Previously, Thomas Bückle was development engineer and project leader in electronic development at Daimler and EvoBus. Benjamin Fernandez has a degree in Mechanical & Electrical Engineering from ITESM, Mexico, a degree in Mechatronics from the Technical University of Hamburg-Harburg and an MBA from NIT Hamburg. He is a development engineer at GIGATRONIK Technologies.
path. The “Turn-Over driving” mode is available for a turn-
in the “Assignment” state, in which the radio link between
ing maneuver at the headland. If an obstacle is reported
the two vehicles is produced. After assignments have been
along the planned path, the slave seeks out a collision-free
made to the two vehicles, the system transitions to the
detour path in the “Evasion” mode.
“Safety Stop”. The slave is now in the “Active Stop” state. Now the “Emergency Stop” can be triggered at any time. To
Safety Concept and State Machine
initiate driving operation, after enabling by the driver the
Safety is a key aspect in the development phase of an un-
vehicles are coupled to one another in the “Docking” state,
manned vehicle. Based on ISO 25119, typical tools are used
provided that their relative positions and orientations al-
to identify risk sources and weaknesses related to the func-
low this. The system transitions to the “Operation” state,
tional safety of a machine, and these risk sources and
and the slave is able to drive autonomously. It starts in the
weaknesses are addressed by suitable measures. A risk
standard driving mode “Parallel Driving”, then any other
analysis yields an Agricultural Performance Level (AgPL)
driving mode can be activated. Risk of collision is detected
for each scenario studied in the product life cycle, from
by environmental sensors consisting of 2D laser scanners
which requirements can be derived for hardware and soft-
and 3D cameras, and detection leads to an immediate
ware. The electronic drawbar is based on a three-stage
“Safety Stop”.
safety concept (Figure 2). >>In the “Operational” state, there are no critical error
Prototype Development at Distributed Sites
messages or warning messages; the planned path is free
Implementation of a complex modular assistance system
of obstacles. >>The “Safety Stop” (SSt) state is understood as an active
with external project partners requires a detailed specifica-
stop for driving and working drives. >>The highest level of the safety concept is the “Emergency
individual partners are not harmonized, a distributed archi-
Stop” (ESt) state. Here, the engine is shut off immedi-
ware modules communicate with one another over a pro-
ately, and the electronic parking brake is engaged.
prietary edaugCAN bus and over TCP/IP Ethernet.
tion of interfaces. Because the development platforms at tecture was selected, in which different software and hard-
Development of a Cooperative Tractor-Implement Combination
The safety concept is implemented in the form of a state
While driver assistance systems such as adaptive cruise control and lane-keeping assistants are increasingly handling
machine which is active as the central software module in
While the project partner was responsible for implementa-
both vehicles which sets the synchronized overall system
tion of navigation functions (NAV), access to proprietary and
state. Figure 3 shows the state machine of the electronic
customized Geo data servers (GIS) and access to vehicle
drawbar. At the system start, the “Default” state is active
control (EXT) via the main controller and user interface for
longitudinal and lateral control of vehicles in road traffic [1], in the agricultural industry the trend towards driverless systems is making progress. This trend is also being supported at the “Chair for mobile machinery” of the Karlsruhe Institute for Technology (KIT) in conjunction with electronic drawbars for agricultural machinery developed by the companies AGCO and “geo concept” [2].
Currently, there is great interest in automated driving in
vehicle configured as a slave follows with a prescribed
the automotive industry. This topic is also gaining in impor-
longitudinal and lateral offset. The work settings of the
tance in the development of agricultural machines. In a re-
master vehicle to implement the local work process are
search project at the Karlsruhe Institute for Technology, a
copied by the slave while still stationary. Good operability
new system has now been developed, in which a manned
and a high level of safety are achieved by the use of envi-
agricultural machine drives ahead as a lead vehicle, and an-
ronmental sensors to detect obstacles (Figure 1) and web-
other one follows it autonomously and driverless. The goal
based geo-information.
Hardware Architecture
initially.
the standard terminal (HMI), KIT implemented the state
The role of the tractor can be set as master or slave. After
machine (ZST), and environment detection (UFS) on a rapid
setting roles, an assignment must be made to both vehicles
prototyping platform.
of the project is to increase area performance and optimize machine utilization in agricultural business without incur-
System Functionality
ring additional personnel costs.
Five driving modes are available to the driver in operating the electronic drawbar.
10/42
Electronic Drawbars for Tractors
The “Parallel Driving” mode serves as the starting mode
The electronic drawbar makes it possible to operate two
and working mode. Here the slave follows the driving track
tractors simultaneously with just one driver. This involves
of the master and performs the same work task. If the
using two tractors of the same type, equipped with identi-
slave follows exactly in the driving track of the master, then
cal implements and highly precise RTK-GNSS receivers
the “Tracking” mode is useful. The “Ignore” mode makes it
(Real-Time Kinematics) and to interlink them via data
possible to quickly decouple the slave to perform independ
radio. While one tractor, which is configured as the master
ent driving maneuvers with the master. When leaving this
vehicle, drives ahead with a human driver, an unmanned
mode, the slave joins up with the master on its current
Figure 1: Prototype setup for testing environmental sensors of the slave tractor
Figure 2: Safety concept of the electronic drawbar
10/43
Development of a Cooperative Tractor-Implement Combination
Data Communication
and to validate the software under the most realistic con-
filter options, graphic signal display and an overview of im-
piled for CANoe and integrated in the remaining bus model.
The physical medium used to exchange system and operat-
straints possible. Not only in the automotive industry, but
portant communication parameters such as bus load and
Since the serial interfaces of the PC could be accessed in
ing data within the vehicles over the proprietary CAN pro-
in mobile machinery as well, ECUs, sensors and actuators
error messages. Any desired ECUs can be operated virtual-
CANoe, the radio path could also be integrated in unmodi-
tocol was the tractor’s ISOBUS. By choosing 11-bit identifi-
communicate in different networks simultaneously. Gener-
ly or as real ECUs by activating or deactivating the network
fied form and be tested for data integrity.
ers, both buses can be operated in parallel without any
ally, comprehensive software tests are not possible until
nodes in CANoe. The bus interface is via an interface from
problems. Each hardware module has its own CAN-ID, un-
the ECU’s interfaces can be supplied with realistic values.
the company Vector. CANoe can also run test scenarios
Summary
der which all relevant signals are transmitted via multiplex-
To avoid having to perform time-consuming and compli-
fully automatically and report on the results. These test
The electronic drawbar has not only proven to be complex
ing. The bandwidth-intensive environment data is trans-
cated software tests in the real system in the development
scenarios may be defined in table form or in XML, CAPL [3],
with regard to the innovative aspect of object detection
mitted over TCP/IP-Ethernet. A low number of nodes and
phase, an RBS can be used to virtually simulate the remain-
C# or graphically.
and integration of geo-information in a harmonious safety
network load permit real-time sending and receiving of
ing network environment of an ECU. Software tests per-
data. Radio communication between the vehicles is in
formed in this way are cost-effective, fast and noncritical
Modeling the Electronic Drawbar in CANoe
system, the specification and maintenance of data inter-
full-duplex mode. The modems used are linked via RS232
in terms of safety.
CANoe is well-suited to this project configuration, especial-
faces is a supportive task that must be taken seriously by
ly in early validation of ECUs, because coordinating testing
all parties. When multiple companies are cooperating on a
interfaces. Master and Slave continually exchange data on position
CANoe
dates and options with the test vehicles is often critical.
project, a clearly specified modular system and software
and movement states, the system state, settings of work-
Vector’s CANoe software flexibly supports the develop-
The approach using RBS enables parallel development
architecture quickly proves to be an important foundation
ing drives, the vehicle state and environmental information
ment of network communication. The structure of a CAN
paths, which can later be easily merged.
for quick progress in the project. However, rapid prototyp-
(Figure 4). Pragmatic organization of the interfaces en-
network is fully simulated in CANoe with the help of net-
A comprehensive model of the electronic drawbar was de-
ing systems in conjunction with RBS software represent a
ables uncomplicated implementation and validation of
work nodes, in which the communication behavior of the
veloped at KIT that could be used to simulate the individual
project-assisting toolbox for efficiently validating subfunc-
subfunctions. Timeouts and checksums were used as safe-
nodes is stored. In addition, user interfaces, signal genera-
ECUs as well as the entire communication with the partner
tions and entire ECUs so that they are successful in sub
ty mechanisms for diagnosis of typical data transmission
tors and other communication interfaces can be created as
vehicle. The ZST, NAV and HMI software modules were
sequent field testing.
errors. This guarantees the data integrity and activity of
network nodes. The event-driven or interactive behavior
modeled as network nodes here. The depth of detail of the
the nodes. If a timeout is exceeded on the CAN bus or in the
can be simulated in CAPL, a C-like programming language
individual modules varies within the model. While all mes-
Translation of a German publication in HANSER automotive,
radio path, this immediately leads to an “Emergency Stop”,
[3] or, for example, with the help of compiled Simulink models.
sages controlling the system state were simulated in their
September 2014.
because it is no longer possible to assure control over the
In a database, all messages that occur, including signal
full functionality, data integrity could be validated suffi-
vehicle.
structure, are stored and assigned to individual network
ciently by assigning constant test parameters in the re-
Image rights: Lead Figure: Vector Informatik GmbH Figure 1 – 4: KIT
nodes. CANoe offers multibus capability, i.e. it supports
maining messages. The use of CANoe in conjunction with
Remaining Bus Simulation to Support Software
both proprietary and standardized protocols such as CAN,
the model-based programmable of the remaining messages
Development
J1939 or ISO11783 as well as FlexRay and Ethernet. For
dSPACE platform proved to be especially helpful. After the
In the development of ECUs, the remaining bus simulation
modeling and time-synchronous evaluation, it offers a set
exchange of platform-specific I/O blocks, the messages for
(RBS) is a powerful tool that is used to support debugging
of stimulation and tracing functions with many different
the developed Simulink models can be immediately com-
Figure 3: Model for defining the operating state
10/44
and operating concept. In a continually changing prototype
Figure 4: Communications architecture in prototype
10/45
Literature: [1] Winner, H.; Hakuli, St.; Wolf, G. (2012). Handbuch Fahrer assistenzsysteme (“Handbook of Driver Assistance Systems”), 2nd edition, ISBN 978-3-8348-1457-9. Vieweg + Teubner Verlag, Springer Fachmedien Wiesbaden GmbH. [2] Zhang, X.; Geimer, M.; Noack, P.O.; Grandl, L. (2010). Development of an intelligent master-slave system between agricultural vehicles. pp. 250-255. IEEE. Intelligent Vehicles Symposium. 6/21-6/24/2010. San Diego, CA, USA [3] Marc Lobmeyer/Roman Marktl: Programming ECU Tests More Efficiently – Tips and Tricks for the Use of CAPL. In: CAN Newsletter (2014), H. 2, pp. 42-43 Links: Homepage KIT: www.kit.edu/english/ Homepage Vector: www.vector.com Product Information CANoe: www.vector.com/canoe Bernhard Jahnke (Graduate Engineer) is a scientific assistant at the Chair for Mobile Machinery of the Karlsruhe Institute for Technology (KIT).
Hans-Werner Schaal (Graduate Engineer) is Business Development Manager in the areas of Automotive Ethernet, Car2x and open CAN protocols such as J1939 and ISO11783 at Vector Informatik GmbH.
10/46
Prototyping and Testing CANopen Systems Reaching Goals Rapidly with Minimal Effort CANopen established itself as a standard for cost-effective and flexible networking of components in numerous application fields ranging from industrial automation to commercial vehicles. Standardized device profiles simplify communication between bus nodes and facilitate smooth interplay between the ECUs, sensors and actuators from different manufacturers. A specialized prototyping and test tool not only performs valuable services in developing complex CANopen projects, but also in providing a fundamental introduction to the subject area.
The bandwidth of tasks in the development of CANopen
cost and effort. Bottlenecks are built into the process
systems ranges from developing individual ECUs to config-
during the test phase, since generally only one test setup is
uring and starting up total systems. For system producers,
available.
the initial use of a system such as CANopen is associated
A way out of this dilemma might be offered by a software
with an incalculable startup effort. In the framework of the
tool that could be used to create a prototype of the future
V-model, a large share of development tasks involves verifi-
total system in a simple way. Optimally, this tool would also
cation and validation. The risk of detecting errors too late is
offer extensive test functions.
minimized by comprehensive tests at the earliest possible time (Figure 1).
Figure 2: Sample configuration of a simple, simulated CANopen network with central control and I/O node
Creating a Prototype Environment with Tool Support Above all, prototypes of total systems networked by CAN
System Verification with Test Setups
should support testing and validation activities. In addition,
Systematic tests accompanying the development of a to-
it is important to represent the individual components by
tal system are indispensible in all development steps. Often
real or simulated ECUs. This makes it relatively easy to test
it is possible to test, but not until a very late time, when
the functional capabilities of real ECUs over the course of
The behavior of the CANopen ECUs is defined in descrip-
(control module). This is how all PDO (Process Data Object)
actual system components are available. Then, the system
system development.
tion files (EDS – Electronic Data Sheet) that are selected
interrelationships are defined in the prototype system.
completion date is at risk if problems occur.
Creating a prototype for a complex total system is a com-
or created beforehand. This next step is to define the inter-
The tool automatically computes the resulting mapping,
In practice, tests are not performed on the real system at
plicated endeavor in which it pays to use suitable tools.
relationships between calibration data that will later be
which can be modified later if necessary. From this config-
the customer’s facilities, rather test setups are used for
CANoe .CANopen from Vector offers valuable assistance in
exchanged over the bus, e.g. the “PressureValve” input of
uration information (DCF – Device Configuration File) the
this purpose. Besides special measurement or diagnostic
creating communication for the prototype system. In just a
the device with address 5 (pressure transducer) is linked to
user now generates the prototyping environment, i.e. CANoe
setups, in testing they also include actuators for simulating
few configuration steps, it lets the user create a prototype
the “Gas pressure” variable of the device with address 10
generates a counterpart for each real ECU with identical
system environments as realistically as possible. Depend-
whose communication properties match those of the later
communication properties. When CANoe is started, the
ing on the project size, such a test setup could incur much
real system.
communications portion of the prototyping environment is already available (Figure 2). Defining Application Behavior The application behavior of individual ECU nodes cannot be derived directly from the EDS files, since they only map the structure of an object directory. Therefore, formulation of application behavior always involves additional programming effort. The CAPL programming language integrated in CANoe makes it possible to program ECU behavior quickly. As an alternative it is possible to code ECU behavior in a DLL that is linked in the prototyping environment under CANoe. It is also easy to integrate Matlab/Simulink models (Figure 3). Test Functionality After the prototype system has been completed, the necessary tests for the total project follow. CANoe supports the Figure 1: Representation of the V-model
10/48
user here, both in creating tests and in logging and evaluaFigure 3: Representation of the CANoe .CANopen environment
tion. The test functionality required for a CANopen system comprises several stages (Figure 4):
10/49
>>Protocol level:
Especially in automated tests, it is important to record the
Tests on this level ensure that CANopen-specific
results of individual test steps in detail. Other CAPL func-
communication protocols of the individual devices are
tions handle writing of test results to an XML file for later
implemented within the total system according to
post-processing. Test sequences for CANoe can also be
s pecification. >>Communication level:
specified under XML. This is advantageous when a large number of test flows need to be generated with a single
What is important here is not the correctness of the
tool. So CANoe utilizes a number of test patterns specified
protocol, but the correct logical order of (independent)
in XML and processes them accordingly.
protocol sequences, e.g. in configuring PDOs. Description of the PDO-relevant entries in the object directory must conform to a specific sequence. >>Application level:
Summary When prototypes are created in CANopen networked systems, this process always involves considerable effort. Yet
Application tests check the relationships between
the process is often essential to prevent findings on func-
process variables. The following preconditions must be
tionality from being delayed until a later project phase.
met to even determine such relationships: First, the
Special tools such as CANoe .CANopen offer the user effi-
process variables must be exchanged via PDOs, and the
cient support in creating prototypes. The requirements for
system must be fully configured. This means, for
technical aspects of communication, in particular, are very
example, that the state of a valve can be checked as a
easy to cover in this way. In every phase of a project, this
function of a temperature or a pressure. Clearly, the user
gives the system developer the test functionality needed to
must have the relevant know-how to formulate the test.
check and verify components completed up to that point in time.
Creating and Executing Test Procedures with CANoe Test sequences are formulated under CANoe with the help of the integrated CAPL programming language. Each
Mirko Tischer, Product Manager for CANopen.
CAPL test module represents a separate test consisting of individual test cases, which in turn contain a number of test steps. During the test run, CANoe processes the individual test cases sequentially. Suitable test flow control makes it possible to skip or repeat individual tests. Simultaneously, it is possible to monitor conformance to other conditions and restrictions – quasi in background. This might be done, for example, to determine – while waiting for a specific message of interest – whether a specific other message is sent periodically on the bus.
Figure 4: Test levels in CANopen
10/50
Kai Schmidt (Vector Informatik)
T
he growing complexity of today’s system architectures is associated with an increase in the effort that must be invested in test specification, test creation and test execution during the development of such systems and system components. Test specifications should be available in early phases of the development process, e.g. after the system architecture has been created or during component design. This makes it possible to detect errors early and correct them costeffectively. The development process for a CANopen system can be described based on the V-model. In the first phase, system requirements are defined, which for the most part contain the definitions of individual “use cases”. This information represents the input for the next step, where initial assessments can already be made of the system architecture. Functions are assigned to
Fig. 2: Device functionality
10/52
Fig. 1: Development process of a CANopen system the individual ECUs, and device descriptions can be created for all devices in the form of EDS files (the format of the EDS files was standardized by CiA and is being further developed by this organization in cooperation with industry). In addition, communication relationships between the ECUs can be configured, as network management and error detection mechanisms. EDS files describe significant parts of the functional scope of a CANopen device. These device descriptions form the foundation for executing the simulation and creating test specifications. Communication-specific tests can be derived directly from the device descriptions. An example of this would be a test that checks all
objects in the object dictionary by SDO accesses and records the results. Besides c ommuni c ati on -s p ec ifi c tests, application-related tests can also be specified. An example of such a test would be to stimulate the transmission of the digital input of an I/O device. Afterwards, a check is made to verify that the signal value exists at the output. Both tests could be used early in the simulated overall system. As soon as the stability of the overall system has been achieved, development of the individual components can be subcontracted. The EDS files can – with the exception of application-related behavior – be considered as a requirements specification for the supplier. Parallel development of the ECUs at the suppliers is accompanied by the simulated overall system. Application-related tests can also be utilized at the supplier to test the behavior of the device to be developed within the overall system. This can signifi-
CAN Newsletter 2/200
cantly reduce the number of cost-intensive changes desired by the OEMs – which generally occur within the integration phase. Communication-specific tests can be created at the supplier in a similar way as at the OEM. After completion and acceptance of the components, they are successively integrated into the simulated overall system. The previously created communication and applicationrelated tests can now be applied to the system, consisting of the physical components and the rest-of-bus simulation. As soon as all of the components have been delivered the concluding test of the real overall system follows.
Tools
Tools
Automatic testing of CANopen devices
glect this work step. Faulty or incomplete EDS files are the result; in the worst case there is no EDS file at all for a device. The development process described above shows that it is not just device producers who need to be concerned with creation of EDS files, but system designers too. The task of the system designer here is to distribute functionalities to the individual components. These could be standardized functionalities such as mechanisms for process data communication, but they might also be manufacturer-specific functionalities. Both of these are mapped via objects in the object dictionary. CiA specifications describe standardized functions. Standardized parameters (process data, configuration and diagnostic data) as well as manufacturerspecific data can be stored in a database format that is also standardized. The necessary objects can be selected from the object pool that is created in this way, and be assembled into an object dictionary. The device descriptions contain all of the information necessary for simulation of the CANopen device. The overall system, consisting of the individual device descriptions, is parameterized utilizing a suit-
able configuration tool, and an initial system description is obtained in the form of device configuration files (DCF), whose format has also been standardized by CiA. Based on this configuration, simulation models can be generated and executed in a suitable runtime environment. At an early point in the project, this already enables conclusions about the time behavior of the overall system. If excessive bus loads occur, for example, actions can immediately be initiated to correct the problem, since suppliers have not been involved in the development process yet. Accordingly, the simulated overall system offers a high degree of flexibility. It can be refined iteratively until it satisfies the defined requirements. Changes to the simulated system can be implemented cost-effectively and be checked immediately.
Derivation of test sequences Besides the simulation, it is also possible to derive initial tests on the protocol and communication levels from the device descriptions. The protocol test includes checking of the SDO protocol, for example. The communication tests do not check for correctness of the
protocol, but instead for correct flow of message sequences. For example, it is possible to test whether the configuration sequence for process data objects conforms to the sequence specified in CiA 301. The following test templates with general application can be defined for a CANopen device: ◆ SDO download test ◆ SDO upload test ◆ Heartbeat producer test ◆ Heartbeat consumer test ◆ Transmit PDO test ◆ EMCY test Test functions are created for each object contained in the object dictionary here. The test functions are parameterized based on the data contained in the configuration files for the devices. Among other things, test sequences can be generated to check the: ◆ PDO configuration ◆ Default values ◆ Object dictionary ◆ NMT state machine, and ◆ SDO protocol The generated tests may be executed right away in a suitable runtime environment. In the framework of integration work, it is precisely such tests that are used to check the delivered components. In turn, suppliers can generate similar test sequences to assist in development. They can immediately be applied to the
Generation template for each version Generation templates must be created for each test, but they are applied to each device to be tested. A generation template that describes the creation of a test for checking the object dictionary would appear as follows: for all objects { get access type if(access == read only){ add test function SDO Upload to test sequence } // if else if (access == read write){ add test function SDO Upload to test sequence add test function SDO Download to test sequence } // else if . . }
The generated test sequence created based on this test template contains a number of parameterized (by entry of object index, etc.) write and read routines. They are processed sequentially in test execution.
EDS files as the basis for tests The development process should include the creation of an EDS file appropriate to the device. Unfortunately, practice shows that device producers often ne-
prototypes. Essentially, this is a way to generate test sequences of the conformance test (CiA 310) device-specifically. However, the goal of the system should not be to replace the CiA conformance test altogether. The system should accompany the development and give developers a way to test devices in advance of the actual tests. The final certification is only performed by CiA.
Iterative development process Since iterative processes are applied throughout a device’s development, the
Fig. 3: Test sequences of a CANopen system
10
CAN Newsletter 2/200 10/53
es receive or send them. Among other things, precisely these aspects must be tested. This subject matter can be explained by the
Tools
process for generating test sequences must be repeatable as often as needed. Changes to the device design can affect the device
Fig. 5: Generated test environment the signal is also unsupported. Even if these requirements could be implemented, it is not possible to automate generation of application-related test sequences, since the behavior of the system is not described.
Generated test environment
Fig. 4: “GPS date” object description descriptions. The test that was originally generated would then likely fail. Nonetheless, it is still necessary to be able to manually extend test sequences after generation, e.g. to incorporate application-specific supplements. These extensions must be read back when the sequence is regenerated.
Application-related tests The application-related behavior of the devices can not be represented in the device descriptions. Furthermore, the tester does not want to have to deal with the CANopen-specific conceptual world and its definitions on the application level. On this level, it is entirely unimportant to know which signal is mapped to which object at which position. More important is information about which signals exist and which devic-
example of the CiA 447 application profile (application profile for special-purpose car add-on devices): The standard defines an object “GPS date”. Mapped to this object are the signals “GPS date year”, “GPS date month” and “GPS date day”. The CiA 447 profile, besides defining signal allocations in the objects, also defines the transmission type. The standard specifies that the object value “GPS data” is transmitted by SDO protocol. The following information is needed to transmit a signal as part of a test: ◆ Index + Sub-Index of the object ◆ Signal length ◆ Start position of signal within the object The format of today’s EDS files is unable to describe the signal allocations of object values. Accordingly, information such as the signal length and start position of
Nonetheless, the developer can be supported by gener-
T
he Codix 538 display by Kübler provides a CAN/ CANopen interface in order to display locally any user-defined value. Numerical values can be directly scaled using a factor or offset from the display device. The display has a floating decimal point that can be inserted in any position. Via the CAN network encoders can be read out directly, thanks to the Automatic Operational Mode. The display is provides automatic bit-rate detection and up to 16 node-IDs that can be set via rotary switches. The CAN port supports base and extended frame formats with maximum datarate of 1 Mbit/s. The display comes equipped with a 6-digit, 8-mm high-red 7segment LED. Each segment can be directly written to, allowing not only val-
12 10/54
ation of an “interaction layer” in test creation. If this extension can be integrated in the simulated overall system, then it is easy to create application-related test cases. The test system consists of the simulated nodes that are extended to include an “interaction layer”. One or more physical devices are tested. The simulated devices are stimulat-
ed via generated interface functions. Signal values are mapped to object values and the CAN messages are sent. In the example depicted, the signal value “GPS date month” would be mapped to the relevant position in the object value (startbit 16, length 4 bit). Parameterization of the test functions assumes that the positions and length of the signals are
Display communicates with encoder ues to be displayed but text messages also. There will always be room for the display, thanks to its DIN housing that measures 48 mm x 24 mm, with an installation depth of just 59 mm. Reverse polarity protection likewise facilitates installation. On account of its high IP65 protection rating the display can be easily used in industrial environments without the need for an additional protective housing. The company offers several encoders with CANopen connectivity since many years. The Sendix absolute encoder features now an additional incremental track. Parallel to the CANopen output this encoder outputs an additional TTL compatible signal with 2048 puls-
es per revolution. As well as the CANopen output, the encoder is also fitted with an RS-422 interface, which outputs the signals A,/A, B,/ B. “This means it is possible to implement simultaneously both positioning via the CAN network and direct feedback of the speed – all in just one encoder,” said Pierre Brucker, Marketing Director at Kübler. “This saves on the costs and installation space that a second encoder would have entailed.” Using the variable PDO Mapping in the memory the user can decide, which information is to be available in real-time. Functions, such as the transmission of speed, acceleration or exiting the work area, ensure fast data availabil-
known. Moreover, the transmission type must be considered. This information is described exclusively in the standard and must be considered in test creation. Use of an “interaction layer” enables signal-oriented test creation. It will be possible to define the function “Send_GPS_month” and generate its implementation based on the CiA 447 specification, if it exists in XML format in the future. Today’s format of the specification requires converting the specification to a readable format (XML or Excel). This conversion task can be assumed by a generator. The generated functions contain a mapping of the signal to the object value and a routine for sending the CAN messages. During test creation, the test engineer need not be concerned about signal positions, indices or transmission types. All the test engineer is interested in are the signal name, sender, receiver and signal value. kai.schmidt@ vector-informatik.de
ity while reducing the load on the bus and controller. The real-time position acquisition of the expanded CANopen Sync function enables genuine time-synchronous position detection of several axes. Kübler is also lunching slip rings (ISTSR085 and IST-SR060) that can be used to transmit bus signals between a stationary and rotating platform. Typical applications include cranes, rotary tables, etc. The transmission between stator and rotor units takes place via sliding contacts (for current up to 40 A). Thanks to their fully encapsulated housing (in high-grade glass-reinforced plastic), high protection rating (up to IP 64) and resistance to vibration, these rugged products are suited to industrial use. www.kuebler.com
CAN Newsletter 2/200 10/55
MED Software Tools
MED Software Tools
T
raditional development processes that reached innovation and quality through a cumbersome development process are no longer appropriate. Studies of Vector Consulting Services show that especially in critical softwareintensive systems, the cost of rework on the product life cycle can be reduced by 30 to 50 percent by improving the requirements engineering.
For example, if quality requirements are misunderstood, problems will arise with concerning usability, security and performance. Since clinical workflows are difficult to model due to their high combinatorial complexity and a rather low standardization but also their ad-hoc character, medical requirements engineering must exhibit specific techniques for medical and health care needs.
Increasingly, companies put their development on a diet. Cost reduction is the dominant goal, but it is also about shorter cycle times, faster implementation of innovations and thus to compete in global competition. Lean and agile means achieving business objectives with an efficient and flexible process. The case study shows how lean requirements engineering (LeanRE) can be used for cost optimization. Our framework was the implementation of Lean Development in medical technology.
We want to show the benefits of systematic requirements engineering by means of a case study with development of an imaging platform for medical technology. A distributed IT system was developed that is specifically adapted according to the respective hospital needs and environments. It included more than five thousand requirements and had several hundred developers at different locations worldwide. Lean Development was combined with requirements engineering, to specify for customer-oriented requirements and progressively refine the outcome. The need for a clear feature orientation was met with product line engineering. Our starting point for the improvement was an analysis of the current state of practice.
Architecture-based modeling provides a clear link between the external view (Why? business benefits; What? requirements, features) and the internal perspective (How? architecture, modules, code, test cases) and thus achieves consistency without overheads. The existing architectural model has been adapted to provide the link at any time from the feature model, and in order to model and maintain variabilities.
Based on these observations, the life cycle has been carefully adapted. Unlike typical increment structures, which are derived from the requirements based on dependencies, our focus was a direct reference to the requirements development. The implemented approach 'Feature-Oriented Requirements Engineering', based on the principles of Lean RE, had the following properties:
Our experiences with Lean RE in the field of medical technology can be transferred well to other application domains. Let us briefly highlight the major experiences in implementing Lean Requirements Engineering in concrete projects:
The push for innovation in healthcare is accelerating constantly and accordingly the demands placed on medical technology are growing. In order to shorten lengthy development and approval processes, many companies change their development approaches towards iterative and concurrent engineering approaches. However, without systematic requirements engineering the probability is high that a project fails.
Software-intensive critical systems in medical technology are under immense market pressure. While they must be technologically innovative, and exhibit safety without any compromise, the global markets require an ever shorter cycle time with simultaneous efficiency pressure. The answer to this is increased productivity through lean and efficient development processes.
11/0
Figures Vector Consulting
Lean Requirements Engineering
www.med-eng.de
The marginal utility of new and changed functionalities needs to be comprehensible at any time.
basis of workflows in the language of the user, because only on such basis a market-oriented product development and positioning is possible.
+
+
Incremental Requirements Engineering with a direct link to project management in order to achieve earned-value implementation.
Practical Experiences
1. Separation of problem and solution space. The development of a solution affects the view and understanding of the underlying problem. With the clear separation of the problem and solution space, the subsequent change requests can be effectively reduced. We achieved a better handling for early impact analysis and estimation of the necessary changes to existing architecture and systems.
+
Feature Model, which is maintained for internal dependencies (e.g. variant management, testing, and documentation) and external relationships (e.g., marketing, product management) and is at the heart of all engineering artifacts. All requirements are modeled first at the previous feature model and evaluated before they are specified in detail and taken into the product.
2. Increased understanding of customer requirements. Users often have an implicit understanding of the requirements. However, they are often unable to articulate precisely what they need. They want to achieve a benefit which still needs to be described and translated to specifications. These requirements should be refined as early as possible. We use a glossary that guarantees the connection to the user language, as well as rapid prototyping to create concepts for user interfaces.
+
Value-oriented evaluation of all features in order to preserve the economic perspective of Lean Development from the requirement elicitation to the feature prioritization to delivery. The marginal value of new and updated functions must be transparent at all times.
+
Graphical modeling of workflows to support the user and usage of every requirement, and to quickly uncover dependencies as well as errors. The user benefit must be tangible on the
49
MEDengineering INTERNATIONAL 2016
»
3. Storyboards for workflows with high share of user interfaces. The Storyboard is a container for related requirements,
MEDengineering INTERNATIONAL 2016
user interface visualization and test cases. It allows representing the case of application but also failure modes, and is refined iteratively with time boxing. For security requirements we specifically apply abuse cases, misuse cases and confuse cases.
4. Structured requirements for planning and budgeting. At the beginning of a project, the additional effort to provide better structure must be invested. According to our experiences, project managers should estimate about 8-10 percent of the project budget for requirements and related architecture analysis. This will improve understanding of dependencies between features and thus reduces errors from not understanding complex behaviors and previous implementations. According to our experience, the appropriate requirements structure will be achieved with three to four iterations. This achieves the necessary stability for the further evolution of the solution. The requirements should be best organized hierarchically along certain functional, that is clinical, domains.
5. Development of a suitable model for traceability. Ad hoc links between requirements and results of the specification to the test cases and documentation without a clear strategy will always reduce the quality and thus foster rework. Therefore, traceability must be established with a clear focus and content orientation. It must define the necessary artifacts that need to be linked, specify the granularity and describe mechanisms for methodology and its implementation in underlying ALM/PLM tools. For medical-technical applications, a well-maintained and intuitive traceability is crucial for market approval such as by FDA regulations. It is essential to maintain the dependency relationships. We recommend to determine the responsibilities for continuous maintenance of traceability relationships in advance and to foresee the necessary effort. This also facilitates an early impact analysis and earned-value based progress tracking and cost control on the basis of implemented and tested requirements.
6. Disciplined use of standards and reviews. Only with clear internal guidelines for requirements engineering, for the work product structure and for procedures and responsibilities, there is some guarantee that the results are consistent across all products for solution development and
50
www.med-eng.de
11/1
of the project. Document templates allow compliance with documentation standards. In addition, standards facilitate the necessary routine for reviews, which are often neglected under project pressure – with the result of complicated and time-consuming rework. www.vector.com/consulting
MED Software Tools MED Software Tools
Conclusion CONTACT CONTACT
can be economically as is can economical- maintained, of all change projects fail. It is not the lack of technology, can be economically maintained, as is in clinical today. We lyrequired maintained, as ispractice but the lack of professional change management compeVector Consulting Services GmbH requiredof in lean clinical practice today. We The introduction and systematic implementation requirements engineerecommend the use of industry stanrequired in clinical tence. Vector Consulting D-70499 Stuttgart Services GmbH recommend use of stanring needs effort both in development aspractice well aswhich attoday. thethe sources of industry requirements, dards, are adapted to the needs We D-70499 Stuttgart Phone + 49(0)711 80670 1525 dards, which are adapted to the needs i.e.Phone product management, and sales. Often this effort is of the project. Document templates + 49(0)711 80670product 1525 marketing recommend the use Therefore, seen it is necessary to capture the benefits of Lean of the project. Document templates aswww.vector.com/consulting too high and too time-consuming, so of that the requirements continue to tripleEngineering quantitatively and to prove that allow compliance documentatiindustry stan-withRequirements allow compliance with documentatiadwww.vector.com/consulting hoc in the project where they are implemented in piecemeal fashion and with for the Requirements Engineering create a on standards. addition, standards dards, which areInadthe expenditure on standards. In addition, standards lots of rework – until once more a project misses its goals or must be aborted. From facilitate the necessary routine reapted to the needs return onfor the investments. A profound cost-benefit analysis, facilitate the necessary routine for rethe many failed change projects which we have seen we know the dilemma: Imviews, which are often neglected under pressure the result of of the project. Document templates allowproject compliance with– with which we conducted in the underlying medical case study views, which are often neglected under projectand pressure – with the result of feature-oriented requirements engineering provements inand methodology, training tools are notshowed addressed complicated time-consuming rework. documentation standards. Inprocesses, addition, standards facilitate thatbethe complicated and time-consuming rework. cause the initial effort to these improvements is considered to be too high. the necessary routine forinitiate reviews, which are often neglected approach can save about 15 to 20 percent of an annual No surprise that 60% of all change projects fail. It is not the lack of technology, Conclusion under project pressure – with the result of complicated and R&D budget. The benefits are distributed as follows across Conclusion but the lack of professional time-consuming rework. change management competence. project cost: Product definition (25 percent), project planThe introduction and systematic implementation of lean requirements engineening (23 percent), architecture (7 percent) and improved The needs introduction and systematic implementation lean requirements engineeTherefore, it is necessary to capture theasbenefits ofofthe Lean Requirements Engineering effort both in development well as at sources ofverifi requirements, Conclusion cation and reviews (45 percent). needs effort both well and as atsales. the of requirements, ringproduct quantitatively andintodevelopment prove thatmarketing theasexpenditure forsources the Requirements i.e. management, product Often this effort is Engiseen i.e.too product management, marketing and sales. this seen neering create a and return onproduct the investments. A profound cost-benefit analysis, as high and too time-consuming, so that the requirements continue toistriple The introduction systematic implementation of leanOften reTheeffort benefi ts of lean requirements engineering can be related as too high and too time-consuming, so that the requirements continue to triple which we conducted in the underlying medical case study showed that the fea- Some, such as better delivery accuracy or ad hoc in theengineering project where they are implemented in piecemeal fashion andfactors. with quirements needs effort both in development to several ad well hoc in where are implemented in piecemeal fashion with ture-oriented requirements engineering approach can save about 15rework, toand 20From perlots of rework until once more a project misses goals ormamust be aborted. as asthe at –project the sources ofthey requirements, i.e.itsproduct less create directly tangible benefits. Others, such as lots of rework – until once more a project misses its goals or must be aborted. From cent of an annual R&D budget. The benefits are distributed as follows across prothe many failed change projects which we have seen we know the dilemma: Imnagement, product marketing and sales. Often this effort customer satisfaction, are more opportunistic and become theseen many failed change which we have seen we know the dilemma: Im- form of good, lasting customer relationships ject cost:asProduct definition (25 percent), project percent), archiprovements in methodology, training and tools are(23 not addressed beis too high andprojects tooprocesses, time-consuming, soplanning that the tangible in the provements in methodology, processes, training and tools are not addressed betecture (7 percent) and improved verification and reviews (45 percent). cause the initial effort toto initiate improvements is considered to befurther too high. requirements continue triplethese ad hoc in the project where with projects. Overall, our experience has shown that cause the initial effort to initiate these improvements is considered to be too high. No surprise that 60% ofinall change projects is not technology, they are implemented piecemeal fashionfail. and Itwith lotsthe oflackaofdoubling of the effort for Requirements Engineering toNo the surprise that 60% of all change projects fail. It is not the lack of technology, The benefits ofprofessional lean requirements can beor related to wards several factors. but of management competence. rework –lack until once more achange projectengineering misses its goals must 10 per cent of project budget in the areas of methodobut the lack of professional change management competence. Some, such as better delivery accuracy or less rework, create directly tangible be- training and tool support will deliver project be aborted. From the many failed change projects which we logy, processes, nefits. Others, such as customer satisfaction, are more opportunistic and become Therefore, it isknow necessary to captureImprovements the benefits of Lean Requirements have seen we the dilemma: benefiEngineets of more than 20 percent. That is a return on invesTherefore, is form necessary to capture the benefits of Requirements tangible in it the of good, lasting relationships with further projects. ring quantitatively and to prove that customer the expenditure for Requirements Engi- than 4, even by only considering the directly in methodology, processes, training and tools areLean notthe adtment Engineeof more ring quantitatively and to prove that the expenditure for the Requirements EngiOverall, our experience has shown that a doubling of the effort for Requirements neering create a return on the investments. A profound cost-benefit analysis, dressed because the initial effort to initiate these impromeasurable benefits. Reason enough for you to evolve your neering create a return on the investments. A profound cost-benefit analysis, Engineering towards 10 per cent of project budget in the areas of methodology, which we conducted in the underlying medical case study showed that the feavements is considered to be too high. No surprise that 60% own requirements engineering towards ‚Lean‘. which we conducted in tool the engineering underlying case showed that the perfeaprocesses, training and support willmedical deliver project benefits of 15 more 20 ture-oriented requirements approach canstudy save about to than 20 ture-oriented requirements engineering can 15considering to 20 properpercent. is aR&D return on investment ofapproach more than 4, save even by only cent of anThat annual budget. The benefits are distributed asabout follows across cent of an annual R&D budget. The benefits are distributed as follows across prothe directly measurable benefits. Reason enough for you to evolve your own requiject cost: Product definition (25 percent), project planning (23 percent), archiject cost: (25 verification percent), project planning percent), rements archiengitecture (7 Product percent)definition and improved and reviews (45(23 percent). tecture (7 percent) and improved verification and reviews (45 percent). neering towards 'Lean'. The benefits of lean requirements engineering can be related to several factors. The benefits lean requirements engineering can becreate related to several factors. Some, such asof better delivery accuracy or less rework, directly tangible beDr. Christof Ebert Some,Others, such asissuch better or lessare rework, directlyand tangible beManaging Directoraccuracy of satisfaction, Vector Consulting Services, where he nefits. asdelivery customer more create opportunistic become supports companies worldwide in product development, IT nefits. Others, such as customer satisfaction, are more opportunistic and become tangible in theand form of good, lasting customer relationships with further projects. change processes. tangibleour in the form of good, lastingthat customer relationships with projects. Overall, experience has shown a doubling of the effort forfurther Requirements Overall, our experience has shown that a doubling of the effort for Requirements Engineering towards 10 per cent of project budget in the areas of methodology, Engineering towards 10tool persupport cent of will project budget in the areas of of more methodology, processes, training and deliver project benefits than 20 processes, training and tool support will deliver project benefits of more than 20 percent. That is a return on investment of more than 4, even by only considering percent. That is a return on investment of more than 4, even by only considering the directly measurable benefits. Reason enough for you to evolve your own requiArnold Rudorfer the directly measurable benefits. Reason enough for you to evolverements your own requiengiis program manager for the development of a system platform rements engiat Siemens Healthcare Diagnostics. neering toneering wards 'Lean'.towards 'Lean'. Dr. Christof Ebert www.med-eng.de isDr. Managing Director of Vector Consulting Services, where he Christof Ebert supports companies in productServices, development, is Managing Director worldwide of Vector Consulting where IT he and change processes.worldwide in product development, IT supports companies and change processes.
51
MEDengineering INTERNATIONAL 2016
51 51
MEDengineering INTERNATIONAL 2016 MEDengineering INTERNATIONAL 2016
Arnold Rudorfer isArnold program manager for the development of a system platform Rudorfer at is Siemens program Healthcare manager forDiagnostics. the development of a system platform at Siemens Healthcare Diagnostics.
11/2
www.med-eng.de www.med-eng.de
Improving Engineering Efficiency with PLM/ALM
be understood and optimized with the impacted engineers.
are the right engineering processes and if they are auto-
Rising cost pressure is forcing manufacturers and their suppliers to jointly and consistently master product development.
An efficient electronics development builds upon stream-
mated and instrumented with appropriate tools [1,2]. PLM/
lined processes that are understood and practiced by all
ALM integration has been a problem in the industry for a
engineers, because workflows are well orchestrated and
long time. On the one hand, customers generally do not re-
optimally support engineering tasks. Success with ALM and
place their favorite point solutions, such as Jazz and
PLM implies that processes and tools are simultaneously
TeamCenter, requirements management with PTC Integrity,
Our industry case study shows how a leading automotive OEM over time has achieved effective interaction of engineering processes, tools and people on the basis of product and application life-cycle management (PLM / ALM). Its scope is first an introduction to PLM/ALM on the basis of a model driven engineering (MDE) for one or several products or product families. Second, PLM and ALM need tool support to the degree necessary to ease handling and drive reuse and consistency. Third, introducing MDE needs profound change management. Starting from establishing the relevant engineering processes, we show how they can be effectively automated for best possible usage across the enterprise and even for suppliers. We practically describe how such a profound change process is successfully managed together with impacted engineers and how the concepts can be transferred to other companies. Concrete results for efficiency improvement, shorter lead time and better quality in product development combined with better global engineering underline the business value.
improved.
development tools like Matlab/Simulink or Rhapsody, and
We will show with this article how engineering processes
replace them with a single suite from one vendor. Even where
can be improved and automated, thus enhancing efficien-
the PLM/ALM part is replaced with a single suite, there are
cy, quality and lead time. Such changes need leadership
often other tools to integrate with, such as defect tracking,
and good orchestration to be successful. We therefore
change management, document management, etc.
show how a sustainable change process is successfully
To work efficiently, engineers need to handle a multitude of
managed together with impacted engineers and how the
processes and different forms of knowledge to be shared
concepts can be transferred to other companies.
with colleagues across business processes and even beyond the borders of the enterprise [1]. PLM/ALM helps to inte-
11/4
1. Improving Efficiency with Better Engineering Processes
stakeholders with individual knowledge about projects,
2. Product Life-Cycle Management
grate those along the entire life-cycle of a release or prod-
Companies and entire industries are changing very fast at
products and processes. As a result, engineering results
Product Life-Cycle Management (PLM) and its equivalent
uct or beyond to an entire portfolio as is illustrated in Fig-
this time.
such as specifications, documentation and test cases are
in software, namely Application life-cycle management
ure 1. Many companies have realized in this fierce climate
Software and IT are the main drivers of innovation. Soft-
inconsistent, items like signals and parameters are arbi-
(ALM), is the overall business process that governs a prod-
that their traditional rather organically grown tools land-
ware-intensive systems as used in automobiles, aircraft,
trarily labeled, changes create lots of extra work to make
uct or service from its inception to the end of its life in order
scape with isolated unconnected processes not only won’t
medical, transportation, utilities and industrial automation
sure that nothing is overlooked, and reuse is hardly possible
to achieve the best possible value for the business of the
scale up but also limit their engineering productivity due to
deliver today 50-70 percent of the value of these solutions,
due to the many heterogeneous contents. This pattern is
enterprise and its customers and partners. PLM/ALM com-
manual data exchange, too much rework, inconsistencies
and this will further grow. The products and solutions must
amplified when collaboration across supplier networks
bines processes, people and tools for the effective engi-
and insufficient reuse across products and platforms
meet increasing quality requirements, but must be devel-
comes into the picture, as it is today normal in systems de-
neering of products – from their inception until end of service.
(Figure 1, left side). A federation of processes and support-
oped cost-efficiently, should be easily adaptable to new en-
velopment.
It involves tacit knowledge of experts and explicit knowl-
ing tools with clear responsibilities improves efficiency by
vironments and must effectively exploit the advantages of
A brief example shows the significance. A supplier is intro-
edge, codified in procedures, process and tools. PLM/ALM
more consistency, quality, reuse and not the least employee
modern technologies. At the same time new competitors
ducing MDE based on some methodology, processes and a
stretches from know-how to know-what and know-why.
motivation (Figure 1, right side).
are pushing new solutions on the market, and the technol-
modern tool environment that enables seamless collabora-
There is a huge misconception that PLM/ALM is a product
PLM/ALM needs both process and tools support. Figure 2
ogy landscape is increasingly cluttered.
tion across development centers and with partners and
not a process. By definition, it is the process by which orga-
shows this relationship based on a study at London Busi-
This economic climate enforces two trends in engineering
customers. In advance, cost-effectiveness was evident be-
nizations manage the creation, deployment, and operation
ness School [1,2]. The horizontal axis portrays the degree of
across industries, namely fast innovation and also cost ef-
cause the system was going to provide faster access to
of software over its full lifecycle. In practice, PLM/ALM has
tools support in an engineering environment, while the ver-
ficiency. Companies invest in growth through innovation by
data and less defects and budget overruns due to improved
been associated with tooling suites aimed at managing the
tical axis shows to which degree the processes are opti-
developing new products and solutions. At the same time
change and configuration control. After the introduction
tasks of this lifecycle, but vendors have rarely delivered on
mized. All four combinations of high versus low have an
they are aware of the volatile market situation and thus
phase however, a MDE tools environment was available,
the promise of integrating the management of the full ap-
associated impact on engineering productivity. Obviously
challenge their development teams worldwide to be as lean
but did not deliver useful models. Engineers were still draw-
plication lifecycle. PLM/ALM is only cost-effective if there
the upper right quadrant shows best performance impact,
and efficient as possible. A senior R&D manager of a lead-
ing their previous style pictures, without much modeling
ing automotive tier 1 supplier summarized it as follows:
methodology. What happened? The tool was designed to
“Cars sell in quantities we have never seen. Markets around
support development and was integrated into the compa-
the world are keen to get latest technology with their cars
ny-wide PDM system. Electronic developers but also prod-
such as energy efficiency, functional safety or internet ac-
uct managers and project leaders could not work with it
cess. But we have learned our lessons from the recent re-
and created parallel systems for their documents, which
cession and made engineering and production flexible to
they exchanged between one another using traditional
immediately react if sales drop.”
methods. The solution would have been simple if it had
There are numerous levers for engineering efficiency im-
been made clear, before introducing the new tool, which
provement. Many companies operate with distributed
processes had to be supported and how these processes
PLM: Connecting processes, persons and tools Traditional
PLM
Design Impl.
Unit test
Integration
with heterogeneous interfaces, redundant and inconsistent
An objective-driven tool introduction, which achieves mea-
data management and insufficient transparency which re-
sureable improvements and is accepted by engineers, re-
sults have been achieved and what needs still to be done.
quires good preparation and implementation. Normally,
Configurations
The underlying root cause is the lack of a shared conceptual
multiple departments or entire divisions are affected by a
model of the product. In consequence, activities such as
change of engineering and tools processes. Before debat-
PDM, CM, defects, documents, etc.
project management, pre-development and product engi-
ing tools solutions, the processes have to be under control
neering are rarely integrated well due to the diversity of
and the envisaged workflows and work organization must
Project management Project data
Marketing
Economic thinking and behaviors
Communication, negotiation
Leadership
Team work, collaboration
Self management
Technology understanding
Maturity / accountability / trust
Design CAD, Code, modelling Collaboration ERP, Wikis, File systems
Tools
Project management Supplier management Requirements management
Architecture, development
Validation, integration
Service
had to be first improved and then automated.
Innovation and change
Product mnmt
teams leading to fragmented processes and tool chains
Strategy
Processes
Organically grown tools
Marketing
Req. Spec.
Competences
People
Fragmented tasks
Change control, configuration management
Figure 1: PLM integrates processes, people and tools for effective engineering
11/5
Improving Engineering Efficiency with PLM/ALM
namely 20%. Introducing the right process first and em-
>>Variant management and product line engineering for
create additional frictions and delays. Our consulting proj-
way of developing and acquiring information. Further the
phasizing its understanding in engineering has a higher val-
effective reuse >>Support for quality requirements such as functional
ects show that the root cause is often the same: Implemen-
information was spread over several data sources and a
tation of efficient processes with adequate tools support
common version control was not really possible.
ue (upper left field), than pushing an engineering tool without profound process understanding (lower right field).
safety from requirements to concept, models, realization
with sustainable results requires profound change man-
Objectives and Solution Approach: The objectives were to
Note that the values of course depend on the specific sce-
to validation, proof and acceptance
agement – which is rarely taken into account. To manage
increase the engineering efficiency, the quality and consis-
nario and environment. What matters here is the ratio be-
such change and to ensure that impacted engineers not
tency of the working products and to shorten the existing
tween the four fields.
There are different ALM/PLM environments available today
only pay lip service but actively support and buy into the
lead times in the electronic engineering. The solution ap-
Tuning processes, improving project management, and
on the market, such as the general purpose solutions from
new processes and tools, their needs and typical work flows
proach was to implement a seamless information manage-
establishing visibility on new product introduction – tech-
Dassault, Siemens, and PTC which had evolved from me-
must be understood to avoid that process overheads and
ment of engineering data from function to software and
niques well described by common improvement frame-
chanical engineering with design and product data man-
heavy tools solutions hinder their creativity. This implies
hardware. That is, centralized information (i.e. model)
works, such as CMMI [4] – will not yield sustainable bene-
agement, and IBM and Vector with specific solutions hav-
pro-active preparation way before a tool decision is made
management in a distributed and decentralized engineer-
fits if not adequately supported by tools. The prospect of
ing grown from software centric applications. We will focus
and good leadership, coaching and support through pilots
ing process. The main characteristics of such a solution
new, high-margin products, combined with the delayed
in this case study on Vector’s PREEvision, a leading auto-
and roll-out.
were alignment of processes, single source of information
impacts of resource allocation decisions, seduce product
motive PLM solution, due to its use by the company which
We will show a case study from a leading automotive OEM
for collaborative teams, reusability of information, using
managers into starting more projects than their develop-
we portray. Like the other state of the practice PLM/ALM
how to successfully introduce PLM/ALM and modeling.
commercially available tools, and continuous development
ment resources can handle.
environments, it provides a complete tool suite of integrat-
Initial Situation: The main drawbacks of the initial situation
with consistent underlying models.
The scope of a PLM/ALM system is on the one hand the
ed data and process management modules [3] (Figure 3).
were non-connected tool chains and a document driven
Change process: To adequately support the introduction and
creation and management of engineering data in one com-
These state of the practice PLM/ALM solutions provide a
subsystem and component engineering process with a lot
change process we recommend a change methodology that
mon engineering data backbone and on the other hand the
repository and editor of different models (Figure 3, left
of manually managed interfaces. Therefore the organiza-
is adapted to specific business goals (Figure 4). PLM/ALM
management of processes. PLM/ALM as a concept and
hand side) and ways to link models to reality (Figure 3, right
tion had to deal with a time-consuming and expensive re-
introduction is a long term activity which has to be funded
solution applies to software engineering as well as to sys-
hand side). This allows both a process-oriented way of
views/rewriting process, a lot of redundancies and incon-
by sufficient competence and budget and competent inter-
tems or hardware products. It applies to different types
working (rigid) and a repository-based way of working
sistencies which often were not detected by these reviews,
nal resources. The necessity of a change must be accepted
and sizes of companies, because it is not prescribing a solu-
(flexible, all engineers share a bunch of models of the prod-
not standardized naming conventions and an ineffective
broadly in the organization and the reliable commitment of
tion suitable only for big companies but rather a clear focus
uct). Compared to the more traditional code generation
on processes along the life-cycle. We use it for complex
oriented MDE no process consisting of planned model
solutions with multiple hardware and software compo-
transformations is defined or required.
nents as well as simple software services.
Based on a rich and extendable data model for features
Today such environments need to satisfy a variety of needs
representing the logical and the physical system architec-
for integrated systems engineering, namely >>Integrated business logic and one comprehensive data
ture and the software architecture, PLM/ALM systems
model for the entire E/E development process from
uration and change control, issues are connected to system
provide highly integrated use cases. For instance in config-
requirements, through system, SW- and HW-design to test. >>Architecture Design and Management
data objects, the related realization date is fixed in the re-
>>Collaboration environment for requirements and test
are planned in the project management module, the change
lease planning module, the implementation time and effort
Engineering, modeling of functions, components,
of the related software parts are managed in the source
networks and communication
code management module and finally the test are planned
Tools without processes are nothing; processes without tools are not good enough
and executed in the test data module. Being able to not only reuse information but also guide engineers through complex tasks generates immediate re-
High
+ 8%
+ 20%
specifically during last-minute changes and corrections under time pressure. Or, consider the time and effort necessary to move engineers from one project to another. Having standardized PLM/ALM solutions around a standard product life-cycle reduces the learning curve to allow focusing on real technical challenges instead of organization
Low
Process focus
turns by making engineers more flexible and avoiding errors,
0
+ 2%
overhead. 3. Industry Case Study
Low
High
Figure 2: Tools without processes nothing; processes without Toolaresupport tools are not good enough
11/6
Integrated Development with PREEvision Product Lines
(Reuse, 150% Model, Variant Management)
Requirements (Links, Attributes)
Logical Architecture (Domains, log. Functions, Activity Chains)
Customer Features
Feature Function Network
Architecture and Design
(Use Cases)
SW Architecture
Mapping
(AUTOSAR, SW Components and Compositions)
(Decoupling of Layers, Variant Management)
SW Implementation
HW Power Concepts
(Simulink „Gray Box“, Parameter Values, Basis SWCs)
(incl. Fusing Concepts, …)
Communication
HW Grounding Concepts
(Data Element, Signal, PDU, Frame, Bus Schedule, …)
HW Components
HW Wiring Harness
(Internal Structure of ECUs, Sensors, Actuators, …)
(Cables, Connectors, Pins, …)
HW Network
HW Geometry
(Bus Topologies & Conventional Communication Connections)
(Packaging, Environmental Requirements, …)
HW Schematics (Electric Functions, Components, …)
Often the expected benefits from modeling and PLM/ALM
Consistency Checks
Reporting
(Document and HTML Generation)
Metrics
(Calculation of Quality Characteristics)
tools are often not visible. They are perceived as complex and employees are frustrated and continue working with their current work practices. New processes and interfaces
Figure 3: PREEvision solution
11/7
Improving Engineering Efficiency with PLM/ALM
users and initiating “Jump Start Projects”. In these projects
Introduce model-based development intelligently and
ness case is clear: With a degree of 30 % for modeling, error
the main requirements of the customer and it must have
the client’s engineers were supported by well known and
step by step, focus on critical components, continuity of
rates and development costs are reduced significantly.
the potential to grow with the growing needs of the user
well with local specific engineering knowledge experienced
requirements to code and test cases, and improving
What did we achieve with PLM? Since we consider knowl-
base. The change partner must be reliable and the chemis-
consultants, which have been trained in PLM/ALM before.
try between the main actors should secure the probability
Such "Jump Start Projects" are focused and have a pre-
the top management is a key. The process tool has to fulfill
edge management a regular management activity, we followed through like in other improvement projects by look-
defined duration (typical two months).
improvement. Measure the implementation, and try in
ing into performance results from real projects, as well as
Lessons Learned: Utilizing a consistent product life-cycle
each project ten to twenty percentage points improve-
some process-related aspects, such as knowledge utiliza-
But if they are true success is not necessarily guaranteed.
and process repository is a necessary condition for reducing
ment, at the spots where you want to put accents, for
tion. We found improved quality, reduced cycle time, im-
Resistance out of the organization, lack of money, changes
cycle time, as they reduce frictions of unclear interfaces
example 20% less cost variations, or 10% less cost in the
proved engineering flexibility, reduced overheads improved
in priorities, pressure from the user groups, theoretic dis-
and responsibilities as well as cutting rework because of in-
test.
communication, increasing alignment of processes and
cussions – these are not the exceptions, these are normal
consistent assumptions and cutting retrieval time for spe-
influences in such a project. The partners have to be able to
cific documents and work products. In implementing PLM/
These lessons learned apply to various type of change
tially improved visibility and aligned terminologies and roles
deal with it and put the best personnel in the position of
ALM and modeling support we found the following lessons
during the introduction and roll-out of PLM/ALM. They can
already brought huge gains, as they facilitate a borderless
learned: >>Concept: First improve the process then the tools based
be generalized for PLM/ALM introduction, or they can be
solution building inside the company.
specifically adapted for a micro-level change, such as a
What is next in PLM/ALM? Knowledge management must
change of a modeling methodology.
be better linked to business. Aligned business objectives
to realize a true long term partnership. These are all necessary conditions for success. If one is a false, failure result.
project leaders and methods/process engineers. Our customer made good experiences with an iterative-incremental development process – short implementation cycles,
on concrete improvement objectives that are set,
early validation with a small group of well experienced pilot
measured and used to correct deviations. Ensure consis-
tools, and faster ramp-up time and skill management. Ini-
and metrics must guide and monitor the development pro-
tency of features and products with a strong systems
5. Summary and Conclusions
cesses, the product lines and the project teams. Take as an
engineering. Specifically in distributed collaborative
For most companies, there is a wealth of untapped oppor-
example a mobile phone or game design with lots of em-
In the rollout phase normally a small group of convinced
environments we see huge benefits from a single data
tunities to cut costs from their development projects. This
bedded software. Being a commodity, business-oriented
pilot users are facing a big group of engineers, which are
backbone for consistent requirements, specs and models
efficiency levers are sometimes obvious, such as incom-
targets cover return rates or brand loyalty. Defects increase return rate and reduce brand loyalty with devastat-
users and a professional change management guaranteed mature deliveries for productive use.
to invest on the one hand more upfront time for learning
across all changes >>Development: Evaluate tools under realistic conditions.
plete and wrong information exchange in a distributed product engineering project. At times they are less obvious,
ing business impacts. Looking to projects, products and
the new environment and to have challenging objectives for
Agree specific requirements to the process and tools
for instance if engineering teams work on different vari-
processes will improve the design away from overly narrow
their normal work products on the other hand .Further-
which are then used to drive changes. Support the inter-
ants that emerge only late during system test or product
focus on manufacturing aspects towards usability engi-
more, migration to a new way of working often includes
faces to the various components and processes through
pilots, such as it was reported from a recent multinational
neering. Knowledge and experience from past projects will
"clean up" of older specifications, which also requires ef-
traceability, automatic consistency checks and test
airplane project.
be embedded into the underlying design processes. We
fort. And there is the small group of engineers, who are
automation. >>Deployment: Manage the changes as they impact the
Inefficiencies are rampant when engineers are distributed
stress the need for adequate knowledge management as a
globally and many different tools being used. Concrete
basis for success in product and solution development – an aspect going well beyond most PLM/ALM approaches of
open for the change in principle, but they are in the conflict
convinced, that the current, traditional way of working is the optimum and that there is no need for a change at all.
entire organization. Pilot changes, coach and train
efficiency and quality improvements with reduced rework
We managed this situation with special trainings for key
engineers, highlight power users that will set the pace.
and faster throughput have been showed by applying con-
today.
sistent PLM/ALM and modeling support. The efficiency and
We should not expect that all product and process knowl-
effectiveness of engineering processes directly influence
edge and modeling methodology can be codified and made
engineering cycle time. For instance earlier defect detec-
available via PLM/ALM. Personal contact will always be
tion in requirements or specs means faster and more com-
necessary to provide context and analysis. The support sys-
prehensive defect correction.
tem should therefore be extended to facilitate interperson-
Without consistent model-based methods and adequate
al communication and evolve towards a global who-is-who
PLM/ALM tools support engineering will be in deep prob-
not only at the operational product/project management
lems within a short time-frame. Increasingly complex re-
level but also at the tactical and strategic level.
quirements must be developed efficiently and with high
Correctness and completeness of the information is anoth-
quality throughout from system engineering to compo-
er aspect that needs to be worked on. We are convinced
nents. Working at a higher level of abstraction and auto-
this cannot be achieved by imposing a reporting discipline
mation will improve productivity and quality. Model-based
only. It can only truly be achieved by ensuring that the pro-
development will play a crucial role in this evolution. The
vider of information is directly benefiting from making the
companies we work with share the same goals: Mastering
information available. This can be achieved to continuing to
complexity, improve product quality, shorten development
evolve the system to ensure information can be captured
time, and plan functions in different variations and versions
as early as possible when it is required at the lowest opera-
for better reuse. The biggest challenges they see are their
tional level, e.g. by supporting period project reporting in
own learning curves and to keep consistency across fea-
presentation format to avoid information is presented first
tures and products. Systems engineering still is undervalued
a set of slides for the project review before it is entered in
and too often decoupled from application development.
the system.
Roadmaps are maintained only for subsystems, and thus
Embarking on a state of the practice PLM/ALM solution
create variants with an overwhelming complexity. The busi-
combined with strong change management triggered by
Vector change model for successful PLM introduction PLM Concept > Analysis: products, processes, tools > Benchmarking: competitors, suppliers, trends > Requirements: Use cases, gaps > Business Case > Measurable objectives
PLM Development > Life-cycle processes: roles, work products, workflows, data models, interfaces > Evaluation criteria > Planning > Commitments (pilot, deployment) > Tool decision
PLM Deployment > > > > > > > >
Piloting Adaptations Power user Incremental introduction Communication Migration of legacy tools Validation vs. requirements Tracking objectives, cost / benefit
Change management
11/8
processes in parallel. >>Operations: Support users and ensure continuous
PLM Operations > Tool and process support > Incremental coverage of all product lines > Coaching > Ensuring sustainability > Optimization > Enhancements
Figure 4: Vector change model for successful PLM introduction
11/9
external support had helped to sustainably achieve the anticipated efficiency effects in the different engineering processes across the product life-cycle. Keywords: ALM, Application Lifecycle Management, PLM, Product Lifecycle Management, Efficiency, Industry Voice Literature: [1] Ebert, C. and J. De Man: Effectively Utilizing Project, Product and Process Knowledge. Information and Software Technology (IST), ISSN: 09505849, Vol 50, No. 6, pp. 579-594, 2008. [2] Ebert, C. and R. Dumke: Software Measurement. Springer, Berlin, Heidelberg, New York, 2007, revised edition 2016 [3] PREEvision. http://www.vector.com/PREEvision [4] Chrissis, M.B., M.Konrad and S.Shrum: CMMI. Guidelines for Process Integration and Product Improvement, ed. 3. Addison-Wesley, Reading, USA, 2011. Dr. Christof Ebert is managing director at Vector Consulting Services. He supports clients around the world to sustainably improve product strategy and product development and to manage organizational changes. Prior to that, he held global management positions for ten years at Alcatel-Lucent. Dr. Ebert serves on a number of advisory and industry bodies, teaches at the University of Stuttgart and has authored several books including his most recent book “Global Software and IT” published by Wiley. Contact him at
[email protected]
Contact: Dr. Christof Ebert, Vector Consulting Services Ingersheimer Strasse 24, D-70499 Stuttgart, Germany. Ph.: +49-711-80670-1525 Fax: +49-711-80670-444 Company: www.vector.com/consulting
11/10
Technical Papers
on the Development of Embedded Electronics
Get More Information
www.vector.com
6th Edition | English
V 6.0 10/2016 - pressbook_en
Visit our website for: > News > Products > Demo software > Support > Training classes > Addresses
Vector – Automotive. Embedded. Engineering.
