Download - HANSER automotive

© Carl Hanser Verlag, München www.hanser-automotive.de Nicht zur Verfügung im Intranet- und Internet-Angeboten sowie elektronischen Verteilern
All this had to be realized in a
compact ECU (Fig. 2) that can
operate within harsh environmental
conditions. Some of the
challenging factors are: limited
mounting space, high ambient
temperatures due to the power
dissipation of the MOSFETS and
strict EMC requirements.
Also the software becomes a lot
more complex than before and
requires more memory and
more calculation performance(e.g.
for the Flexray protocol
stack).
8lA UTOMOTIVE 2008l SPECIAL EDITION FLEXRAY
The microcontroller - V850E/PHO3
A microcontroller that is able to satisfy all the above mentioned
requirements is a rare thing. Taking into consideration
NEC’s very well known high level of quality and long
expertise in the chassis field (e.g. several million microcontrollers
sold for electrical power steering) it was decided
to use NEC’s V850E/PHO3 for the Active Steering and
Rear-Wheel Steering projects (Fig. 3).
In a “nutshell” the PHO3 features a high level of calculation
power, a huge memory (1 MB), the capability to control
BLDC motor actuators, an interface to the FlexRay network,
is able to support the extended automotive temperature
range (A2 grade) plus excellent EMC performance.
In addition an integrated floating point unit has been implemented
as this is required to support today’s approach of
model based algorithm development.
Many chassis applications have similar requirements to
those above , but require more or less performance, resp.
more or less memory. To cover this, NEC have created a
dedicated product line, named “P” Series. The “P” series
offers strong solutions for low, mid and high-end chassis
applications.
Key parameters of the FlexRay Network
The FlexRay network is the key component which facilitates
the fast exchange of data. This makes it possible for the
actuators to behave in a coordinated way and demonstrate
optimized quick reactions to compliment the physics of
driving.
As the FlexRay protocol was designed to allow a high flexibility
a huge amount of parameters have to be chosen.
One key parameter is the cycle time. As the FlexRay configuration
should be unchanged for all cars within the 7
Series platform and also future car series, it was a very difficult
task to find the optimum balance required between
network throughput and network load.
Initially it was felt beneficial to have a high frequency of
messages. But this would mean that seldomly sent messages
would waste the network capacity. Finally it was
decided to use a 10 Mbit transfer rate and 5 ms cycle time
within the static and dynamic segments over a single channel.
Although a network based purely on a passive bus
would be preferable from cost
point of view, it was finally decided
to use a combination between the
passive bus and star coupler. This
was chosen because too many
FlexRay nodes connected to one
cable would detoriate the signal
quality and hence limit the achievable
bandwidth and quality of the
signal transmission.
V850E/PHO3 with Flex-
Ray is running - What is
next?
Fig. 3: NEC V850E/PHO3 microcontroller
As a result of the successful introduction
of FlexRay into the first
series project, other OEMs are now following and will present
cars with FlexRay over the next couple of years. This
means that FlexRay has been established as the automotive
high performance communication protocol and will
become a standard interfaces within the automotive mass
market. In order to support FlexRay for broader application
areas the topology of the FlexRay network has to become
much simpler. Also more flexible concepts are required
e.g. synchronization. This is already on the way with the
FlexRay protocol specification 3.0.
The next big challenge for future chassis ECU’s will be cost
reduction. High optimization potential still can be found in
simplification of the functional safety concepts, by applying
microcontrollers with enhanced functional safety support.
This could help eliminating or at least simplifying components
such as additional monitoring microcontrollers or
supervision ASICs. But it could also dramatically reduce
the efforts on the SW engineering side.
Why not focus on the actual application SW and have the
HW perform all of the diagnostics still being done in SW
like memory tests, core self tests and plausibility check of
safety-relevant calculation results? And why not reduce the
efforts for functional safety validation and the assessment
process in the same way?
Wouldn’t it be a relief to present an “out-of-the-box” selfsafe
microcontroller with proven safety integrity level rather
than generating a new FMEA for each ECU variant,
even though the same microcontroller is used?
All this could be addressed by a generic functional safety
concept for the microcontroller saving tremendous efforts to
set up and validate a new functional safety concept for each
and every product line. NEC Electronics has already started
designing a new chassis microcontroller family, the Px4
Series to meet these demands. It will be optimized for automotive
applications targeting IEC 61508 SIL3 certification
and will use a single microcontroller to cover the span between
a high level of functional safety at minimal costs. NEC
has established a close cooperation with TÜV SÜD to monitor
and assess the development of Px4 from the early conceptual
phase to the final implementation in silicon.
V850E/Px4 will feature an integral safety concept based on
two redundant CPU subsystems checking simultaneous
each others’ operation.