Civil Engineering Reference
In-Depth Information
preferably to standardize any hardware-independent software layers, to specify
clearly their functions and interfaces. As such, no further adaptation is required for
any individual application purpose. Merely software for ECU abstraction layers
and driver layers cannot be fully standardized due to the differences in the hardware
to be controlled and the varying functionalities and options of it. Nevertheless, the
basic functionality as well as the minimum interface towards the higher software
layers can be standardized (see Fig.
6.11
).
6.4.2
Trend Towards Standardization
In the past, software for communication functions often was not developed from
standards but often from scratch always for each new application. The reason for
that certainly was the need to save limited resources of the applied micro-controller
as well as to differentiate from competitors. The trend started from non-standard-
ized solutions, then moving from partial standardization of specific components
(e.g. OSEK/VDX COM and NM, where OSEK/VDX stands for “Offene Systeme
und deren Schnittstellen für die Elektronik im Kraftfahrzeug / Vehicle Distributed
eXecutive”) and customer-specific guidelines as well as quasi-standards of auto-
motive manufacturers (e.g., BMW-kernel) towards open and customer-independent
standards (e.g., Automotive Open System Architecture, AUTOSAR) in the future.
Many benefits arise from standardization such as reuse of once implemented
components, substitution ability of standardized software modules by different sup-
pliers, comparability and long-term reduction of development time and cost. The
generalized applicability of a software module in conjunction with its included par-
tially complex functions which may not even be needed in specific applications,
however, implies the drawback of increased resources consumption, bigger com-
plexity and higher development cost.
Obviously standardization of components only pays off if those components pro-
vide a sufficiently high quality and thus a broad market acceptance and long life-
time. A solution, which due to its high complexity hardly can be handled, and which
despite of the application of standards does not meet the goals of exchangeability
and comparability or which frequently fails, will not prevail the market, which is
characterized by an enormous cost pressure and high-quality requirements.
Therefore, the key is quality of the generated standard software modules as well
as their exchangeability, correctness, performance and comparability. In order to
safeguard these characteristics standardized tests are required which must provide
a preferably high level of quality at reasonable costs. Only this prevents a com-
plex system, consisting of various software modules, which typically are sourced
by different suppliers, from having a correspondingly high risk of failures which,
after the integration phase, are even difficult to be reproduced and localized. This
finally turns out to be a very costly task if and even if the erroneous module(s) can
be identified at all.
