Before Autosar and challenges

Before the development of AUTOSAR (AUTomotive Open System ARchitecture) in 2003, the automotive industry lacked a standardized approach to software architecture, hardware platforms, and development standards.

AUTOSAR was created to address these challenges by providing a standardized software development infrastructure. It’s a global partnership between automotive industry participants, including OEMs, suppliers, semiconductor manufacturers, and software suppliers.

Current supply-chains in automotive E/E development contain hundreds of companies that design their individual hardware and software components based on requirement definitions from the OEMs or Tier-1 suppliers. Clearly, systems integration has become a key challenge.

To ease the integration in the future, the AUTOSAR partnership [He06] (http://www.autosar.org), an alliance of OEM manufacturers and Tier-1 automotive suppliers with many associates, has established a number of de-facto open industry standards for automotive E/E architectures.

Birth of Autosar/Timelines of Autosar

// which companies united for autosar, with what motive it was invented and mention its timeline

//organisation that are established because of autosar

With respect to this background, the leading automobile companies and their first- tier suppliers formed a consortium in 2003, This partnership was established as an industry wide standard for the automobile electronics: AUTOSAR( Automotive Open System Architecture), which is headed by the following 10 “core partners”: BMW Group, Bosch, Continental, Daimler Chrysler, Ford Motor Company, General Motors, PSA Peugeot Citroen, Siemens, VDO, Toyota Motor Corporation and Volkswagen.

Autosar Consortium has different members, mebers in the form of companies that contribute to it. The roles are varied in terms of their contribution and exploitation. These members are divided in 4 categories:

• Premium Members
• Associate Members
• Development Members
• Attendees
• Subscribers

// give small brief about autosar members

Timeline of Autosar:

• The first phase of Autosar started in 2003 and ended in 2006, during this phase 52 premium members, companies of the suppliers and software and semiconductor industries joined the development of this standard and made major contributions in the consortium.

Main Objective of Autosar

• Autosar was set up as a partenership to define an industry wide
• Themost important consequence of the stringent component-based approach of AUTOSAR, concerning the development process ,is as paration of application devel opment from the lower levels of the integration development (basics of software[BSW]). The separator between these two parts is the AUTOSAR run time environment (RTE), which concretely realizes the concept of a virtual functional bus( VFB) as an abstract ing communication principle. The idea of this concept is that an application does not need to know the concrete paths from data and signals below RTE when two applications communicate together.
• The main concept or object of the AUTOSAR architecture is to separate the application software from the basic software and make it independent of the hardware (standardized infrastructure).
• Autosar software architecture provides the scalability of ECU software for serveral car lines and variants.
• Meaning a customer can spend one time developmenr cost to develope and application like a parking assist system and reuse this application on different hardwares for all his car variants.
• The main goal of AUTOSARis to define a software architecture with standardized APIs and configuration files for application and basic software,

What is Autosar

• Autosar was set up as a partenrship to define an industry wide standard for software programing of automotive electronics. Or in more technical way one can say a industry/global level standard for embedded system programing of electronics involved in building automotive systems.
• To overcome the challenges, Autosar defined a new development methodology for automotive software and software architecture. The Development methodology is focussed on a model-driven development style.
• The software architecture is defined without considertaion of the hardware on which the software components will run on later. This means that 2 software components might run on the same ECU or on different ECU’s. The communication between the components is then either an intra-ECU communication or an inter-ECU communication. To abstract from this
• The lightweight Classic AUTOSAR enables companies to perform thorough security testing on systems like electronic stability control (ESC), steering, electric parking brakes, park distance control, infotainment, anti-theft systems, remote keyless entry, and more. By using it, manufacturers can find security vulnerabilities accessible via external channels, such as Bluetooth or other public-facing interfaces.
• Autosar delivers the following standards:
  • Foundation Platform: The purpose of the Foundation standard is to enforce interoperability between the AUTOSAR platforms. Foundation contains common requirements and technical specifications (e.g. protocols) shared between the AUTOSAR platforms.
  • Classic Platform: The Classic Platform is AUTOSAR’s solution for embedded systems with hard real time and safety constraints.
  • Adaptive Platform: The Adaptive Platform is AUTOSAR’s solution for high-performance computing ECUs to build safety-related systems for use cases such as highly automated and autonomous driving.

Layers in Autosar

• Application Layer:
  • Different templates/SWC’s
  • Ports:
  • runnable entities:
  • In this need to understand the different types of SWC’s and then understand the concept of Ports and Runnable entieties in it
• RTE Layer:
  • VFB concept:
  • Ports
  • Interfaces
  • Phases in RTE: Contact phasr and generation phas
  • In this first to understand the concept of Virtual Functional Bus(VFB) and then the concept of ports on how ports are used for mapping of ASW components to BSW modules.
• BSW Layer
  • Service Layer: Service layer is directly allowed to interact with Hardware
    • Non Volatile Random Access Memory manager
    • Diagnostic Event Manager(DEM)
    • COM Stack
    • Autosar OS:
  • ECU -AL :
  • I/O hardware Abstraction
  • Communication Abstraction
  • Memory abstraction and
  • onBoard device abstraction
  • Complex Device Driver:
  • MCAL
    • MCU Drivers
    • memory drivers
    • communication drivers
    • I/O Drivers

In Depth Explanation of Layers:

ASW Layer

• ASW layer contain the software components(SWCs), which realize the application functionality of the ECU.
• The top layer is the application layer that consists of software components that provide various functionalities and services in the vehicle. The two most significant types are the application software component type and the sensor actuator type.
• All the SWC are portable and reusable except the hardware-dependent SWC like Sensor/Actuator SWC.
• Everything that uses the AUTOSAR platform is located in the application layer; this is the part of the system where the components actually do something useful in the vehicle.
  • What are the different Software Components(SWCs) in ASW layer
    • What are Software Components?
      • The main purpose of the Software Components in AUTOSAR ASW layer is to make it reusability and to design a software module independent of Embedded Hardwares.
      • Types of SWC’s in ASW layer:
        • Application SWC
        • Analog Handler SWC
        • Digital Handler SWC
        • Parameter SWC
        • Composition SWC
        • Service SWC
        • Service Proxy SWC
        • ECU Abstraction SWC
        • Nvblock SWC
        • CDD SWC
    • What are these functionalities and services in the vehicle?
    • 
      • Examples of Software Components are:
        • Engine Control Software
        • Adaptive Cruise Control
        • Automatic climate control
        • Lane keeping assist software component
        • Infotainment system software component
        • Battery Managment System Software component
        • Electronic stability control software component
        • Electonic power steering software component
        • Parking assist software component
        • PRessure monitoring system software component
• It is also possible to deliver an ASW component only in the form of object code, for example, in order to protect intellectual property. All necessary information is ECU-independent and already available in the contract phase. With the ASW component-specific header file it is possible to compile the source code of a given ASW component. The resulting object code together with the header file can then be delivered as a bundle to the customer.
• ASW layer is also not allowed to use any BSW module directly.
• ASW components have dynamic behaviour and is implemented by “runnable entities”.
  • What are runnable entities?
    • Runnable entity is a part of SWC where the application behaviour logic is written. Runnable is analogous to functions in C.
    • These are the smallest pieces of code (basically C-functions) which implement the SWC functionality.
    • There are generally 3 types of runnables:
      • Init Runnable:
      • Periodic Runnable
      • Server Runnable
• While configuring runnable developers must mention the trigger point, Ports, Port Interface and Port Connectors . It tells under which condition the runnable needs to be triggered or called, communication flow between multiple SWC’s.
  • What are trigger points?
    • These are also called as RTE-Events
    • The RTE-Event offers a mechanism to specify when to execute a runnable. For each runnable, an RTE Event defines whether the runnable needs to be called periodically or event-based (e.g. events related to communications like when a mode switches, when an operation is invoked, when a trigger signal is received, etc.).
  • What are Ports?
    • Each SWC is connected with the help of Ports, these ports give communication between 2 SWCs as well as with BSW.
    • Ports are like indiviual end points in SWC’s. Through which data goes or comes inside the particular application.
    • Port is inside the Application Softwrae Components.
    • There are 2 types of Ports:
      • Required Ports(R-Port): This type of port is used when data is to be received or required.
        • 
      • Provider Ports(P-Port):This type of port is used when data is to be transmitted or SWC is a provider of some service to other entities.
        • 
      • Provider-Receiver Port(PRPort):
  • What are Port Interface?
    • Ports are connected with each other via Port Interface. The kind of information these ports can handle decides the port interface. Their are 2 types of Port Interface:
      • Port interface is inside the Aspplication Software Component.
        • Sender Receive Interface: In this data is transferred from one software component to another software components. Data flow from SWC to SWC is done via sender reciver interface. In which Provider Port is sender and Required Port is receiver.
        • Client Server Interface: In this data is tranferred from one SWC to BSW layer. Data flow from SWC to BSW layer is done via Client/erver Interface. In which Provider port is Server and Required port is Client.
        • Parameter Interface:
        • Non-Volatile Data Interface:
        • Trigger Interface:
        • Mode Switch Interface:
  • What are Port Connectors?
    • Port Connectors are used to specify, the location of Ports: Their are 2 types of connectors:
      • Assembly Connector: Assembly connectors are used to connect two ports in a single software component.
      • 
      • Delegate Connector:Delegation connectors are used when some port of SWC needs to be exposed to the outer world of the Composition (ECU).
      • 
  • What are Access Ports?
    • To access the information conveyed via the ports, The access points specify how the runnable expects to access a data (buffered or not) or an operation (synchronous or asynchronous).
  • In the part aboce RTE, ASW components communicate with each other via Ports. Their is no other way of communication allowed.(e.g via shared global variable).
  • 
  • ASW is mostly hardware independent(CDD modules which are used directly in ASW are hardware dependetnt only), communication between ASW and hardware( which is BSW layer) is done through RTE layer.
  • This layer consists of many software components (SWC) which execute the set of tasks to fulfill the functionality of the vehicle. Each SWC contains many runnable. These software components (SWC) are connected with the help of ports. These ports give communication between two SWCs as well as with BSW.

RTE Layer

• RTE establishes communication between the SWCs and sheduling of SWCs.
• The RTE is responsible for mapping the components in the application layer(ASW layer) and the basic software layer(BSW) so that they can communicate and make use of each other’s functionality. The way this is done in AUTOSAR is through the concept of ports. A port is either of type providing or requiring.
• In a way, the RTE is the heart of the architecture, the glue that binds all the other components.
• The RTE is generated in order to ensure that it fits a given ECU and system configuration .This means that an RTE implementation always provides only the functionality that is needed for a given configuration ,and nothing more.
• It act as a middleware between the Autosar Application layer and the lower layers.
• Responsible for establishing communication between application SWCs and BSW modules.
• Responsible for sheduling the runnables. Runnables are triggered based on RTE Events.
• All the Ports and interfaces are implemented in RTE. With the help of ports and interfaces inter-ECU and intra-ECU communication is achieved in AUTOSAR.
• RTE is different for each ECU, and Each ECU has its own customized RTE implementation which is generated during the ECU Configuration process of the AUTOSAR methodology . The ECU mapping, i.e. the information about which component will deployed on which ECU, is part of the input of this configuration process and RTE is not reusable. If the application changes, then RTE also needs to be changed.
• RTE doesn’t support any runtime reconfiguration, i.e. every communication between SWCs and BSW modules must be configured before RTE is generated.
• Its main function is to manage communication between application software components and the Basic Software (BSW) layer. This includes providing APIs for inter- and intra-ECU communication, data exchange, and event handling. The RTE abstracts the complexity of the underlying system, helps in achieving modularity, and enables software components to be developed independently from hardware considerations.
• Technically, communication between the SWCs of same ECU is called Intra-ECU Communication whereas the communication between SWCs of different ECUs is called Inter-ECU Communication.
• Intra-ECU communication is realized virtually by defined function calls in RTE on the other hand the Inter-ECU communication is realized by using the underlying communication bus like CAN or FlexRay through COM Stack along with RTE.
• VFB helps in separating the SWCs and the underlying infrastructure thus making SWCs completely hardware independent.
• The RTE is a layer providing communication services to the application software (AUTOSAR Software Components and/or AUTOSAR Sensor/Actuator components). Above the RTE the software architecture style changes from “layered“ to “component style“. The AUTOSAR Software Components communicate with other components (inter and/or intra ECU) and/or services via the RTE.
• All runnables of a ASW layer should be mapped to RTE events, else they will not be triggered. There are differernt RTE Events:
  • Timing Event:
  • Data Received Event:
  • Operation Invoked Event:
  • Mode Switch Event
  • Data Received Error Event
  • Data Send Completed Event
• For the communication task, the RTE provides a set of APIs for sending or receiving data elements and for remote server calls in the case of client/server communication.
  • Concept of Virtual Function Bus
    • The application layer and BSW layer communicate through RTE with the help of Virtual Functional Bus(VFB).
    • The virtual functional bus is the mechanism that allows SWC’s and BSW modules to communicate with one another.
    • The development of an AUTOSAR System is based on the definition of the Virtual Functional Bus (VFB). The VFB is an abstract communication mechanism that allows software components to interact. This view is independent of any ECUs and networks used. Based on the VFB the system is designed.
    • The VFB is an abstraction of the communication between software components. It provides a dedicated view of all the software components the system contains, independent of any ECUs and networks.

BSW Layer

• The bottom layer is the Basic Software Layer (BSW). This is the only layer that can access the Microcontroller itself. It consists of a number of modules that are used by the Application layer via the Run-time Environment (RTE).
• Autosar standard defines a set of fixed BSW modules. BSW comprises modules like: device drivers, communication and I/O drivers, NVRAM manager or DEM, Autosar OS. In Total Autosar specifies 63 BSW modules. Each of these BSW modules has a clearly defined interface ,which can be employed by other modules or by the RTE. An interface basically consists of a set of application programming interface(API) functions, a set of data types and possible error codes returned by the API functions. Besides that AUtosar also defines a set of configuration paramters for a BSW module. These paramters are divided into precompile, link time and postbuild parameters
• Each BSW module has an AUTOSAR specification that specifies the module’s requirements, data types, and interfaces.
• Again BSW layer is divided into 4 types:
  • Service Layer: Responsible for providing services independent of underlying hardware or protocols like OS, CRC, memory managment, ECUM and Diagnostics stacks.
    • Non Volatile Random Access Memory manager
    • Diagnostic Event Manager(DEM)
    • COM Stack
    • Autosar OS: Autosar OS must be able to access the hardware in order to manage for example the timer for time-sliced sheduling. This is the reason why service layer is allowed to access the hardware/.
  • Complex Driver: The Complex Driver spans from the hardware to the RTE. SWC’s which do not follow Autosar Standard are integrated into the system through CCD. If a anew comminciation system will be introduced then no autosar drivers will be available, to enable the communication for these new drivers will be done by complex device driver.
    • This is also directly allowed to inetract with hardware. CDD layer is to extend the usage of new device drivers of MCU, which are not yet standardixes in MCAL layer.
    • Complex Device Driver is a specialized layer provided in case the application needs to access the hardwrae in a faster way.
  • ECU Abstraction Layer: It makes higher software layer independent of ECU hardware layout. It is a true Abstraction Layer, which isolate the MCU with application software by wrapping over the MCAL drivers to make the API’s general and universally same for all MCU’s. ECU layer is further divided into 4 types:
    • I/O hardware Abstraction
    • Communication Abstraction:
    • Memory abstraction and
    • onBoard device abstraction
  • MCAL : RTD of Automotive microcontrollers for using its peripherals. It is lowest layer of whole Autosar Stack, and it contains Real Time Drivers to use Microcontroller peripherals. It provides the API’s to ECU Abstraction layer and Service layer to use the Microcontroller peripheral via standaridized API’s and parameters. Thus what ever be the Microcontroller, for ECU abstraction and Service layer to use the MCU peripherals same set of API’s and parameters would be used. Only if microcontroller is changed, then we only have to mainly change the MCAL layer and all above it remains same. MCAL layer is further divided into 4 categories:
    • I/O Drivers: It has drivers for peripherals which involves use of digital and analog signal inputs or outpute: PWM, ADC, DAC, ICU and etc.
    • Communication Driver: It has drivers for communication protocols via MCU peripherals: CAN, LIN, UART, I2C, SPI and etc.
    • Memory Drivers: It has drivers for accessing different memory blocks of MCU: Internal/External Flash, EEPROM, Cashe and etc.
    • MCU Drivers: It has drivers for accessing system peripherals of MCU like: Interrupt, Watchdog,
  • .
• Interfaces: through which different software modules interact with each other. . A software component typically has a well-defined interface that specifies how it can interact with other components in the system It is of 3 types:
  • Autosar Interface
  • Standardized Autosar Interface
  • Standardized Interface

Autosar Code Generation Flow

• ,AUTOSAR has introduced as sandardized architecture defined by a metamodel. This will be the basis for the interoperability of products developed using the AUTOSARs standard and a methodology approach for developing according to and complying with the AUTOSAR standard.
• Autosar is based on models, everything in an autosar system needs to be decribed in terms of standardized model elements.
• What are different Autosar Models?
• .The models are not fixed. Infor mation is added both in consecutive stages performed by different roles as well as iteratively by the same role.
• The models are serialized to a standardized XML format for exchange and persistence using XML standard.
• Source Code is generated directly based on the model. So, Autosar models are not merely the documentation of the electronic/electric systems but they also derive the software development of automotive system.
• Their must be a standard format for sharing the Autosar Data and that format is based on XML files. In autosar it is called as ARXML files. AUTO-SAR XML.
• In AUTOSAR Release 4.0 the methodology is specified as a model yielding a set of HTML-documentation

Methodology to Autosar

1. First the vehicle functionalities has to be defined and based on that different ASW components are configured and selected. These Vehicle functionalties are defined in a file, from Embedded software implementation point of view which is known as System Configuration Input. This File is used as an input for Autosar System Configuration tools.
2. After doing so we configure the different SWC’s, runnables, Ports and Port interface of each SWC, based upon the input file and in return we get the XML files, which are termed as system configuration decsription files. This step is done by use of Autosar System Configuration Tools. These files have all information from implementation point of view that which software algorithm would be used in particular ECU, how it will be interacting and etc. This step also generates the .c and .h files for our application software according to Autosar stated standard API’s and format. Configure System step in the flow above is this step.
3. After that from these System Configuration Description Files, ECU hardware specific data is extracted. This extracted data is stored in a file termed as ECU extract of System configuration file, this file is also of XML file format. This file has information of what all communication protocols(CAN, LIN, Ethernet and etc) has to be used, OS services( sheduling techniques, IPC’s, number of tasks and etc) which are needed, Memory and diagnostick services along with the MCU peripheral drivers required for building the final Application.This step is done by which tool? Extract ECU-specific information step in the flow above is this step
4. After that we configure the ECU, by developing, configuring and selection of different BSW modules according to our semiconductor hardware chips and services needed for Application software like: OS configuration, MCAL Driver Configurations, ECU abstraction layer developement for using different sensors/modules, communication stack development and etc etc. This step is done by BSW configuration tools. The output of this step is we get the bunch of .c and .h files which are generated and developed consist of low level software stacks.
5. After that .c and .h files of steps 4 and 2 are combined to generate a full software stack of the ECU and then these files are builded into executable format using make utility tools.
6. And final executable is flashed into the semiconductor hardware chip
7. ARXML file contains a information that hold:
   • System Constrains
     • Details about different software components present in Final ECU.
     • Grouping of software components belonging to same functionality.
   • Software Components:
     • Details like data type of signals involved in communication
     • Connection details between Multiple software components
   • ECU resources:
     • Hardware specific details like processing units, memory details, peripheral units and even contains the hardware pins details.

1. First by selecting ASW components and by identifying the overall system constraints.This requires engineering decisions at the system level ,which means in practice, that the appropriate templates should be filled out.
2. In the next step, we configures the ASW components,develope runnables for each software component, indentify ports, port interface and various other configuration oarameters which are involved in ASW layer.
3. Based upon the software component, ECU specific information is extracted out. As according to Application software components, ECU should have functnalities and features at software and hardware level both.
4. The next activity ” Configure ECU” adds all necessary information for implementation like tasks, shdeuling, main BSW module list, assignment of runnables to tasks and configuration of the BSW modules.
5. The result of configre ECU is included in the ECU configuration description file. It contains configuration parameters based on the vendor specific and generic paramters, the BSW module description and the collection of available ASW components implemented on the ECU.
6. Due to the high complexity of this step, it has to be supported by different tool-related editors. To automatically generate parts of the configuration code for the RTE, OS and COM, certain generators should be used.

1. Abstract System Design: This represnt the entire vehicle function in a functional or Abstract view.
2. Design of Virtual Function Bus: In this different Software compinents(SWC’s) of ASW layer are defined and their ports and communication methods with each other and BSW layer are defined. VFB does not tell how the ECU’s are designed and connected.
3. Software Component Design: Defination of SWC;s are done based upon VFB.
4. System Design: Defining of ECU topolgoies. Linkding of SWC;s with BSW layer and correspondigly ECU’s are designed.
5. Base Software Configuration and ECU integration: BSW module configuration and development is started once the network matrix for the specic ecu is available.
6.  

Autosar Standard Classes

• ICC1: RTE and BSW not standardized, instead they are clubed into 1 cluster. And RTE and ASW is only according to Autosar compliance.
• ICC2:
• ICC3: highest level of autosar compatibility, here all BSW modules are defined by Autosar are present with their corresponding interface. There is no clustering of modules.

Communication Stack

• At the heart of AUTOSAR lies the Communication Stack, commonly referred to as the COM stack, which plays a vital role in enabling communication between different software components within an automotive system.
• The COM stack in AUTOSAR accommodates a wide range of communication protocols, including FlexRay, Ethernet, and MOST (Media Oriented Systems Transport), to meet the increasing demands for higher bandwidth, lower latency, and deterministic communication
• The COM stack addresses these concerns by implementing robust security mechanisms and protocols to safeguard against unauthorized access, data tampering, and cyber threats. Secure communication protocols such as TLS (Transport Layer Security) and IPsec (Internet Protocol Security) are supported, enabling encrypted communication channels between ECUs and external entities
• Additionally, the COM stack incorporates features for secure bootstrapping, authentication, and access control, mitigating the risks associated with software vulnerabilities and malicious attacks.
• The COM stack supports OTA update protocols such as HTTP (Hypertext Transfer Protocol) and CoAP (Constrained Application Protocol), enabling efficient and secure delivery of software updates over cellular or Wi-Fi networks.
• The COM stack provides mechanisms for real-time communication, including support for time-triggered protocols, message prioritization, and deterministic scheduling

Autosar Tooling and Development?

Developing software within the AUTOSAR framework requires specialized tools and development environments. Here are some essential tools and considerations:

1. AUTOSAR Tool Chains: Various vendors offer AUTOSAR-compliant tool chains that assist in designing, configuring, and generating AUTOSAR software components. These tools help manage the complexity of the architecture and ensure compliance with the standard.
2. Code Generators: Code generators are used to convert high-level descriptions of software components into executable code. This automation streamlines the development process and reduces the risk of errors.
3. Configuration Tools: Configuring the numerous parameters and settings in an AUTOSAR project can be daunting. Configuration tools simplify this process by providing a user-friendly interface for defining software components and their interactions.
4. Testing and Validation: Thorough testing and validation are crucial in automotive software development to ensure safety and reliability. AUTOSAR tools support testing by enabling developers to simulate and analyze the behavior of software components

1. EbTressos WinCore
2. Da Vinci tool
3. Mentor graphics
4. Vector tools

Different tools are used to create an AUTOSAR ECU software. These tools can roughly be classified into the following types:

• Tools for system design
  These tools are used to define the network architecture and communication as well as the design and distribution of the SWCs.
• Tools for configuration of the basic software and the RTE
  These tools are used to create a configuration description of the BSW modules of the ECU (ECU Configuration Description).
• Code generators for BSW modules
  Based on the ECU Configuration Description, code generators generate specifically configured BSW modules for the ECU.

Tools:

1. Autosar Authorizing tool: To create a high level design which includes Software Component Description, ECU resource Description and system description file.( including communication matrix, topology and etc). These Files are of AXML file format!!
2. Once these 3 components are ready, then software development process using Autosar methodology can be largely broken into 2 pieces: Application Software Development and ECU configuration process.
3. Application Software Component Development Process: Softwrae Component Description File which describes the software componets that needs to be developed for vehicle. We create a ARXML file for these system components having information filled with runnables, ports, ports interface and etc using AUtosar AUthorizing tool.
4. Next step in to convert the ARXML file into .c and .h files. Many Autosar Authorizing tool have this feature. This .c and .h files is genereic code.
5. ECU configuration process: We use the ECU resource description and system decription file to generate the system description. System decsription has all the mappings i.e it has all the details of ECUs. software components that are mapped to ECU and details of communication matrix , topology. A BSW Configuration tool is used to configure the ECU.
6. BSW configuration tool: Generation of RTE, OS, BSW and MCAL. The output will be .c and .h files.
7. This .c and .h files are integarted with .c and .h files generated in application software compinent process and a final make file is generated.

Autosar Tools:

• System and SW Modelling: It is used to model the ASW and networking. With help of this tool SWC are designed/create and their communication topology is done. ECU extract creation and RTE creation happens. OEMS generally do this part and use thsi tool.
• BSW Configurator Tool: It is used to configure Autosar BSW layer like: MCAL, CDD and ECU Abstraction layer.
• BSW Implementation: It implements the BSW layers modules, that is
• RTE Generator: It is used to generator the RTE

How to start with Autosar Technology?