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

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 5).

ECUC Parameter Model
The ECUC parameter model contains the module the statistics concerning the boxes, parameters, and references. It specifies the relationship among the packing containers and parameters that may be used by the configuration version to describe the module template facts. The top-degree structure of the ECUC parameter model is proven in Figure 1

 fig 1-ECUC parameter model

ECU Parameter Definition elegance (EcuParameterDefinition) collects all references to person module configuration definitions of AUTOSAR ECUC and defines a reference
relationship to the definition of numerous software program modules. Module Definition elegance (ModuleDef) defines ECUC parameters of one software module consisting of BSW, RTE, SWC.

ECUC Model
This step of the ECUC process is not precise by AUTOSAR. The templates are the maximum critical a part of this thesis which facilitates in automating the configuration system rather than manually configuring the BSW. Figure 3 suggests the magnificence diagram with the respective attributes. The structure is primarily based on the configuration metamodel. To assist the developer in growing a template, the model presents numerous auxiliary features. They are meant to facilitate get entry to to sure elements of the model. For example, the complete
configuration of a module ought to be returned via passing its call. It is distinguished among call and reference. The getByName feature searches for a particular call in
the model Uppercase and lowercase letters are taken into consideration. The feature getByRef makes use of a reference string to attain the referenced item. An example of a VALUE-REF tag with reference to the class diagram is proven in Figure 2 According to the magnificence diagram, we get the subsequent capabilities:
getModuleConfigurationByName
• getModuleConfigurationByRef
• getContainerByRef
• getValueByRef
• getArPackageByRef
• getValueByName
• getReferenceValueByValueRefName
• getReferenceValueByDefinitionRefName

fig 2-Value-Ref Structure

fig 3-Class Diagram representing generic module design in AUTOSAR
A certain description of those strategies may be determined within the next bankruptcy. In addition,
there are the usual getter functions for getting a category’s attribute. The setter functions are not implemented to exclude adjustments in values and to hold consistency

Module Configuration Template (MCT)
The BSW Module Configuration Template provides the template of the source code that ought to be generated. The values from the ECUC Description may be inserted into the template via the ECUC Model defined within the next bankruptcy. The template is written in Xtend programming language. The developer of the respective BSW Module is accountable to provide a template for the module configuration. Xtend is used to jot down the module
configuration templates due to its optimized syntax, it permits shorter and readable code and is well matched with Java. The MCT accesses the module values from the ECUC model and describes their characteristic in the ECU. APAG Elektronik affords a library with capabilities that can be used to access the values without increasing the complexity of the code. These capabilities are described in the subsequent chapter. Each template contains a version string. During execution, the version is passed as an argument (-v). Only if the transferred version suits to the template’s version, the technology might be finished. Further arguments are the route to ECUC Description (-ecuc) and the direction to the output (-o). Without these arguments, the generation received’t be commenced successfully. The Module Configuration Template needs to be compiled to an executable and stored with the naming
convention “«moduleName»_BswMCT.Jar”.

Automated Generation of ECU Configurations for
Watchdog Timer
This chapter describes the automated technology of ECUC for Watchdog Timer.The following sections describe the Watchdog Timer in AUTOSAR, implementation of the ECUC version, the module configuration templates and the Basic Software Source Code Generator (BSG) device

Watchdog Timer in AUTOSAR
In order to enable structured software development and to make certain desirable maintainability, extensibility, and portability of the software program, the whole Watchdog Timer module is advanced in keeping with a layer version such as three layers. The man or woman layers simplest communicate with each other through described interfaces. These interfaces contribute to the safety of the software program via preventing the character modules from being able to control any records in any way. In addition, an abstraction of the diverse layers is achieved, so a layer ought to (only) realize the interfaces to its superordinate or subordinate layer, whereby the complexity of the whole device is encapsulated.
The three watchdog
modules are:

Watchdog Driver Module
The Wdg Driver module affords services for initialization, changing the operation mode and setting the trigger situation (timeout). This module is used to at once manage
the hardware watchdog timer and manipulate its function. Table 4.1 indicates the Wdg module data with facts about the containers which can be present in it as special by
AUTOSAR [11]. Each of the boxes has parameters which are defined to perform obligations inside the Wdg Module.

Table 1-Wdg module-specific information

Watchdog Interface Module
In case of more than one watchdog tool and watchdog driving force (e.G. Each an internal software watchdog and an outside hardware watchdog) getting used on an ECU, WdgIf lets in the watchdog manager (or any other patron of the watchdog) to pick out the ideal watchdog motive force - and accordingly the watchdog tool - whilst keeping the API and capability of the underlying motive force. Table 2 shows the WdgIf module records with information approximately the boxes that are found in it as distinct by using AUTOSAR [11]. Each of the bins has parameters which are described to perform obligations within the WdgIf Module.

Table 2-WdgIf module specification information