Introduction to AUTOSAR and its Effect on Automotive Software Architecture(part-4)

Dear readers,
My name is Sadashiv Balawad and I am working as Junior Software Engineer at Luxoft India. Luxoft gave me many opportunities to work on various projects, which inspired me to talk about the importance of Autosar and its impact on automotive software development (Part 4).

Extract ECU-Specific Information
The tool AUTOSAR ECU Configuration Extractor (ex. System desk, Da-Vinci) extracts the data from the System Configuration Description wished for a particular ECU. This is a one to 1 reproduction of all factors of the System Configuration Description that are mapped to this specific ECU. The network database (ex CAN.Dbc) document is the enter to produce ECU extract ( .Arxml ).

Configure (BSW) ECU
The ECU configuration in particular offers with the configuration of the RTE and the Basic Software modules. The configuration is primarily based at the parameters which are available inside the ECU Extract of System Configuration. BSW additionally includes the Vendor-Specific ECU Configuration. This is vital due to the fact the output ECU Configuration Description has a bendy shape that does not define a fixed range of configuration parameters at the same time as ECU extract.
The conversation module, MCAL, the running gadget, or AUTOSAR services ought to be described during BSW configuration.

Generate Executable
After the ECU configuration is done, a software supply for numerous modules of the ECU may be generated. This refers to the Basic Software (e.G. Conversation module, operating machine, and so forth.), and the RTE.
The configuration, supply code technology and generate executable ECU code resemble today's improvement practice. This is specifically a linking of all additives. There are extra steps involved. E.G. Facts from the ECU Configuration Description is probably used to generate specifically configured executable software program.

SW-Component Implementation
The initial paintings of SWC begins with imparting the necessary components of the software program thing description [SWCTempl]. That is Component Internal Behaviour Description as a part of the software program thing associated templates. The inner behaviour describes the scheduling applicable elements of a thing, i.E. The runnable entities and the events they reply to. Furthermore, the behaviour specifies how a factor (or extra precisely which runnable) responds to events like obtained facts elements. However, it does now not describe the particular useful behaviour of the issue

Configuration Classes
The mission of compiling and linking is needed to create an executable (programmed binary), then the executable must be downloaded (flashed) to the hardware. AUTOSAR
specifies for these steps 3 distinct times for configuring a BSW module. The “precompile time”, “hyperlink time” and “publish-construct time”. Each of those instances has influences on the EcuC Description. The Pre-Compile Time Configuration, proven in Figure 1 is carried out earlier than the compilation.This can cause complete code sections can be excluded from the compiled configurations. The advantage that arises is this way memory area may be
stored, and capabilities will disappear from the compiled files. In order to make the capabilitiesto be had a recompilation of the code is vital.

fig 1-Pre-Compile time configuration chain

The Link Time Configuration is created throughout the link system. Figure 2.shows BSW module which includes two elements, the code, and the configuration. Both are compiled independently of every other. The item documents from the compilation procedure are connected collectively, which resolves present dependencies to external references. After the hyperlink system, the values of the configuration cannot be changed anymore

fig 2-Link Time configuration chain

Figure 3 shows the Post-Build Time Configuration. The module is already related and loaded on the ECU. At this point, the module will recognize the deal with where the
configuration may be discovered in reminiscence. One risk that this type of configuration entails is that there is no guarantee that this location in reminiscence has been flashed with an appropriate configuration, if there is a fault inside the process, it'll now not be detected until runtime. For the other configuration training, the compiler or linker can make certain that the configuration
exists. The benefit of this variant is that the values of the configuration can be modified by means of rewriting the reminiscence area. AUTOSAR distinguishes between two use cases inside the postbuild configuration. First, the previously described case proven in Figure 3 referred to as loadable configuration and 2nd, the selectable configuration, shown in Figure 4 The
20 technique is harking back to the link-time configuration but continues to be taken into consideration as submit-construct. This is because multiple configuration sets are provided at link time. During runtime, more specifically at the initialization of the ECU, one of the current configurations may be selected. Thus, it is able to be stated that the ECU is configured after building.

fig 3-Post-construct time loadable configuration chain

fig 4-Post-build time loadable configuration chain

Configuration Metamodel
AUTOSAR is based on Model Driven Architecture (MDA). It is a software program layout approach that makes use of models for the development of software systems. The model
specification is written the usage of Unified Modeling Language (UML). AUTOSAR is made up of numerous models which can be based on metamodels. One of these metamodels is known as the Configuration Metamodel. This metamodel describes the shape of the configuration version. It in particular includes containers and parameters. Containers are used to institution the parameters and they also can have sub-bins. The configuration version is used to keep
the configuration of the BSW, which corresponds to the BSW model cited inside the previous section. The goal of the metamodel is to make it viable to explain the AUTOSAR unique factors which include the configuration parameters with the same set of language factors. The configuration language generally uses boxes and parameters which describe the values which might be used to configure the ECU. The configuration metamodel is described in parts: ECUC parameter definition and ECUC description.

The ECUC description is written using a template to specify the layout alternate for the configuration values in the ECU. This template is written the usage of ARXML which was explained in one of the previous sections. The ECUC parameter description which is also an ARXML document includes the information on what type of regulations and capabilities are given to the parameters. The dating between the 2 is shown in Figure 5.

fig 5-Parameter definition and ECUC value files