13.02.2013 Views

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

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

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

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

SWC1 SWC2 SWC3<br />

2.6 Configuration Files<br />

. . .<br />

Figure 2.7: VFB diagram<br />

SWCn<br />

Virtual Functional Bus<br />

2.6 Configuration Files<br />

To do the mapp<strong>in</strong>g to the ECUs, which is described <strong>in</strong> section 2.2, it is necessary to<br />

know a lot of <strong>in</strong><strong>for</strong>mation about every part of the <strong>AUTOSAR</strong> system. This means<br />

the precise description of a SWC <strong>for</strong> each mechanism described <strong>in</strong> section 2.4 and<br />

the configuration of the ECUs and the system. This configuration is done <strong>in</strong> an<br />

XML <strong>for</strong>mat <strong>for</strong> a def<strong>in</strong>ed XML scheme. The concrete XML scheme depends on the<br />

<strong>AUTOSAR</strong> release. For one release some different scheme versions can exist, as a<br />

result of bug fixes and updates.<br />

<strong>AUTOSAR</strong> dist<strong>in</strong>guishes two cases of specifications. The specification of a SWC<br />

together with its <strong>in</strong>ternal behavior is called a SWC description. Everyth<strong>in</strong>g that goes<br />

beyond the scope of a s<strong>in</strong>gle component is called a configuration. Together with a<br />

SWC description it is possible to deliver the component to suppliers.<br />

<strong>AUTOSAR</strong> does not specify, which <strong>in</strong><strong>for</strong>mation has to be put <strong>in</strong> which files. Instead<br />

the structure of the files is flexible that the whole configuration can be put <strong>in</strong> one file<br />

or every object can have its own file. To reference an object <strong>in</strong> an XML file a unique<br />

path is used, which consists of the package names that have to traversed <strong>in</strong> the XML<br />

tree to reach this object. An example is given <strong>in</strong> section 2.8.<br />

2.7 Runtime <strong>Environment</strong><br />

The RTE is the implementation of the VFB <strong>for</strong> one specific ECU. It provides the<br />

environment which is needed <strong>for</strong> the SWCs to run on that ECU and communicate with<br />

other SWCs. The RTE encapsulates the communication between the components, so<br />

that they don’t know were the counterpart of the communication is located. This<br />

means, that the communication with a component on the same ECU is done directly,<br />

whereas the communication with a component, which is located elsewhere, is done<br />

through a communication mechanism like CAN or LIN. But the RTE does more than<br />

just provide the connections of the VFB. It additionally ensures that runnables of a<br />

SWC are triggered through the configured events, provides consistency <strong>for</strong> IRVs and<br />

ensures the effect of exclusive areas. Or <strong>in</strong> short, it provides the functions <strong>for</strong> all the<br />

configured mechanisms.<br />

As earlier described the RTE is auto generated from the RTE generator but this is<br />

15

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!