Design process

Hardware
Autosar
Present Problems
The Autosar Standard
The Autosar standard is meant to be a breakthrough that should allow a paradigm shift in vehicular system
design and should lead to
improvement of functionalities and higher safety.
The Autosar project introduces its own terminology, which shall be used throughout the rest of this text. More
information can be
found on the Wikipedia article of Autosar.
Autosar Methodology: a 4-step methodology that can be used to create the vehicular system architecture
starting from the designmodel.
Basic software: Standardized software that doesn’t has any functionalities that are noticeable to the end-user
but offers hardwaredependent
and hardware-independent services.
Runtime environment: implementation of the possible communication paths on a software level.
Application software: The software that implements the actual functionalities, which are noticeable for the
end-users.
The Autosar project has chosen to standardize the communication and the non-functional software, such as
the runtime environment
and the basic software. The functional software, namely the application software, is only standardized by its
interfaces.
This has several implications:
OEMs can build a vehicular system by choosing the best soft- and hardware for each specific application,
without
having compatibility problems. This means that the integration cost decreases. In addition, maintenance is
easier to
execute because the diagnostic services can be standardized for all application instead of being supplier
dependent.
Suppliers can still compete on implementation of the application software components. This should lead to
better
components. Also because of the clear interfaces, suppliers can build, debug, and maintain one version of their
application software for all the different vehicular systems, which reduces proliferation of software. Due to the
clear
interfaces, there is also more option to partition development between suppliers or between teams of a
suppl.ier
Hardware suppliers can still compete on the best hardware, only the basic software necessary to use the
hardware
will be standardized, but there will be options to protect specific software (for example special software to
cancel
non-linear effect of actuators).
New companies can easily enter the market because of the clear set domains. A company should only be an
expert
on his domain.
To raise the safety of a vehicular system designed according to the Autosar standards, several safye tmeasures
are included.[1]
Safety Integrity Functions, which are safety measures to be present in AUOTSAR, independent of the
application
context. These functions support the correct execution of application functions and safety functions. In
general, the
functions are related to protection of resources, monitoring, and self-testing. Extra safety measures of this
category
need to be taken due to the change ins ystem complexity. For example, if two applications can use the same
resources and share memory, it will be necessary to build in some safety; for example to prevent write access
to
data segments of other applications[.2]
Support of Safety Functions that are dependent on the application context. This means the support of typical
safety
functions of systems from the different applications, like a fast reset for critical applications.
General Safety Requirements like local detection of faults without propagation.
Safety features can automatically be added to all vehicular software, which is a big advantage over the existing
approach to vehicular
software design.
The clear set of standards and interfaces reduces the chance of faults due to wrong interaction between
applications.
Terminology
Analysis of the Standard
Reusability
Safety
The Autosar project introduces the concept of component based software design in vehicular software design.
This is a necessary
change due to the growing complexity of the vehicular systems, which leads to a need for teamwork.
In component-based design, it is clear what each component should do, so the design can easily be divided
over
different teams. In addition, the interfaces are standardized which guarantees consistency in data exchange.
The meta-model simplifies teamwork. The formal description of the vehicular systems makes sure that the
structure
of the information can clearly be visualized and that consistency of the information is guaranteed.
Component-based software design facilitates the use of model-based design. Thus the use of model-based
design,
which is a current standard in vehicular system design, can be expanded.
Component-based design shifts automotive software development from an ECU-based approach to a function-
based
approach and makes it possible to write application software independent of the used ECU.
Due to the increasing complexity of vehicular systems, there is a need to explicitly control the interaction
process instead of implicit
definition of the interaction embedded in the different subsystems itself.
In this context, the concept of the four fundamental "concerns" of system design is introduced. These
represent the different layers in
the interaction-process.
Explicit layers facilitate the design of vehicular systems due to the better overview of the interaction process.
Especially changes in
the vehicular system, which requires changes in coordination, are more straightforward.
Communication depends on the used protocols, interfaces and agreements about data exchange formats. This
is
specified in the standard.
Computation depends on the application software components.
Configuration is dependent on the system designer and the used tool-chains for the methodolog. yThe system
designer designs the physical topology of the ECU-network and decides which applications he wants to add to
the
vehicular system. When following the methodolog,y the optimization algorithm in the selected tool-chain
determines
the distribution of the diferent application over the different ECU’s.
Coordination is specified in the runtime environment. The runtime environment is the implementation of the
configuration, has the possibility to manage both inter- and intra-ECU communication and can call the
fdeirfent
applications to handle communication at their communication ports.
The application software only affects the computation step and is therefore not aware of the computation and
configuration layers.
This makes it possible to create application software that is unaware of the number of interaction partners. In
this way, there is a clear
separation between the communication and functionalit.y
The explicit control of interaction makes it possible to add applications to the vehicular system without the
need to change some of
the application software that interacts with the new application. The necessary changes are situated in the run
time environment,
which is automatically adjusted in the ECU-configuration step when using the Autosar methodolo.gy
The AUTOSAR-standards also change the complexity of the vehicular system. Modern vehicle are of the type
distributed hardware
distributed software.
AUTOSAR sees the system as different applications running on one virtual platform. The standards make it
possible to translate the
virtual platform to a real implementation on the different ECU’s, where it is possible that some applications
run on the same ECU.
This methodology paves the way for a shift to systems with distributed hardware – central software.
This new model of a vehicle system has some implications for thesa fety.
Design in Autosar
Component based design
The four fundamental "concerns" of system design
Influence on