Evaluation Environment for AUTOSAR-Autocode in Motor Control ...
Evaluation Environment for AUTOSAR-Autocode in Motor Control ...
Evaluation Environment for AUTOSAR-Autocode in Motor Control ...
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
5.2 Components of the <strong>Environment</strong><br />
run OSEK–OS 5.0 <strong>for</strong> PC This type executes the b<strong>in</strong>ary file <strong>for</strong> the PC–Port.<br />
The b<strong>in</strong>ary is executed <strong>for</strong> a specific time. Dur<strong>in</strong>g this time the b<strong>in</strong>ary can make some<br />
outputs to the standard output. If there is an output, that starts with the str<strong>in</strong>g<br />
“ERROR”, this type is adopted as “failed”. Otherwise it is f<strong>in</strong>ished correctly. As a<br />
variable this type requires a period of time that specifies how long the b<strong>in</strong>ary shall be<br />
executed.<br />
copy to Mx17 PST S<strong>in</strong>ce a complete built of MEDC17 has a size about 650MB,<br />
it is not workable to copy it <strong>for</strong> every test. So the sources of the test are copied<br />
to the MEDC17 directory, to <strong>in</strong>tegrate the test. So just one checkout is used <strong>for</strong> the<br />
whole environment. The names of the copied files are stored <strong>in</strong> the MEDC17 directory<br />
to delete the files be<strong>for</strong>e files of another test are copied to MEDC17. The test type<br />
requires also some variables. These are the location of the PST and the names of the<br />
subdirectories, <strong>in</strong> which the files shall be copied.<br />
compile Mx17 PST The compilation of MEDC17 is not <strong>in</strong>tegrated <strong>in</strong> the environment.<br />
It has to be per<strong>for</strong>med with other build tools, which have to be started<br />
manually.<br />
run on control unit Here aga<strong>in</strong>, the flash<strong>in</strong>g of the compiled MEDC17 to the control<br />
unit and the debugg<strong>in</strong>g of the control unit, have to be done by the user. This<br />
is done with the graphical debugger Universal Debug Eng<strong>in</strong>e, which is the debugger<br />
used at BOSCH.<br />
With this description it is clear that the test type “code review” does not need a<br />
Perl script, because everyth<strong>in</strong>g, which can be done automatically is done by an test<br />
type that is executed be<strong>for</strong>e. So a test type, which is per<strong>for</strong>med by the user, does not<br />
have a Perl file.<br />
5.2.6 Variables<br />
To keep the test types configurable <strong>for</strong> a test template, variables are <strong>in</strong>troduced. The<br />
types e.g. need the name of the ECU <strong>in</strong> the configuration files, <strong>for</strong> which the RTE shall<br />
be created, or a period of time <strong>for</strong> which a compiled b<strong>in</strong>ary shall be executed. Such<br />
variables are def<strong>in</strong>ed by the test type and can be used <strong>in</strong> the Perl files. The variables,<br />
which are required by the different test types, are already mentioned <strong>in</strong> the previous<br />
section. Typically the variables are set by the test templates, but a test type can also<br />
provide a “default value”, which is used, if no other is specified. A variable without<br />
a “default value” has to be set from a test template that uses this test type. A test<br />
type additionally sets a description <strong>for</strong> the variable. The description should expla<strong>in</strong><br />
the purpose of the variable.<br />
5.2.7 Test Template<br />
A test template consists of a number with four digits and a name. The template is<br />
unique identified by the number. The number is also used to sort the templates and<br />
41