Civil Engineering Reference
In-Depth Information
cient; respectively, the valuable resource
CPU-time
of the microcontroller is dissipated
in this case. With AUTOSAR, the hardware will become more comparable: With stan-
dardized interfaces, it is possible to do a benchmark test easier on the driver layer than
on the direct hardware layer. With this comparability on driver layer, it becomes more
important to have a highly optimized driver, which uses the available CAN control-
ler hardware mechanisms perfect to save other resources. This is also valid for other
protocol drivers, like the FlexRay driver, and of course for the peripheral drivers at all.
4.2.3.9
Conclusion
The AUTOSAR standard enables the possibility of microcontroller manufacturers
to provide highly optimized driver for their hardware. These drivers can be used by
the software vendors within their basic software platforms. With an overall accepted
AUTOSAR standard, the huge investment into the drivers and higher software layers
is safe—there is a chance to get a return on the investment. The CAN driver is now
a piece of a much bigger picture and standalone nothing special, but together with
the overall AUTOSAR concept, the model of a layered architecture makes sense.
A legacy software was able to access direct the lowest software layer—the drivers.
It prepares the data, implements all needed mechanisms and calls, e.g.
Can_Write
direct. This direct access was implemented in the past ECU development very often.
Some developers already use quasi-standards for the driver layer to avoid double de-
velopment of the same functionality. Within the higher software layers some modules
were standardized, e.g. the OS was OSEK/VDX compliant. In future, it is needed to
get a high total reuse rate for each single piece of software. A standardized platform
like the described AUTOSAR platform gets more and more important for efficient
software development. The use of this platform pays off as soon as there are first
applications which can be completely reused for a second vehicle generation—not
to be developed again due to a “simple” hardware change (due to cheaper hardware
availability). Another contribution for cost reduction will be the reduction of integra-
tion effort for each single project: Due to standardized methods and increasing AU-
TOSAR knowledge in the overall development community, the integration will be
faster. This cost reduction will only take effect if the AUTOSAR standard is used by
many and every Tier 1 can use the same basic software platform for various OEMs.
The success or failure of this standardization of automotive software architecture is in
the hand of the AUTOSAR core members, especially the OEM. Only if all OEMs use
the AUTOSAR standard “as it is”, the overall AUTOSAR project will be successful.
4.3
Automotive Diagnostic Implementations on CAN
ISO 15765 Road vehicles—Diagnostic communication over Controller Area Net-
work (DoCAN) was initially developed in the late 1990s. The purpose of the docu-
ment set is to standardize the diagnostic communication-related OSI layers for the
purpose of diagnostic and normal message communication.
