Evaluation Environment for AUTOSAR-Autocode in Motor Control ...

Chapter 5
Analysis and Design
The evaluation environment is divided into two parts. The one is the test environment,
which helps to perform tests. The other are the test cases itself, because just with the
test cases the environment can be used for evaluation. The structure and behavior of
the test environment are explained in this chapter, the implementation is described in
the next one. Chapter 7 deals with the test cases itself.
The outline of this chapter is the following. In section 5.1 first an evaluation flow is
described. It should provide the idea of the classification of the components, which is
made in section 5.2. Section 5.3 describes, how these components are configured and
section 5.4 describes how they are stored in the file system of the environment.
This chapter also provides some aspects of the implementation of the environment,
which are explained in the next chapter. This are e.g. the use of Perl files to implement
test types or the use of XML files to store configurations.
The term “components” is used in this chapter to address the in section 5.2 explained
components of the environment. There are not the AUTOSAR software components
meant.
5.1 Test Data Flow
This section provides the idea of the made classification and structuring of the later
environment. The diagram in figure 5.1 shows a simple proceeding of doing a test with
an RTE generator. MEDC17 is not considered in this diagram. The test case consists
of some AUTOSAR XML files, which are fed into the generator to create the RTE.
The RTE not only consists of the auto generated part, but also of the RTE library,
which is fix for one generator. The test case provides source files, which implement
the SWCs that are described in the AUTOSAR XML files. The test case also consists
of some documentation files, which describe the aim of the test in an informal way.
The generator creates OIL files for the configuration of the operating system, but
this is not the whole configuration. So there are some additional files needed. From
this configuration the source code for the operating system can be generated. This is
not considered here in detail, but just displayed in the diagram.
Some additional source files, which e.g. contain the main() function, are also required.
All source files can now be compiled and linked together. The created binary
file then can be executed at a control unit or with the OSEK–OS PC–Port, depending
on for which target the binary is built.
35