Hello Readers,
My name is Aravind B. N., and I work at Luxoft India as a Junior Software Developer. Luxoft has given me several opportunities to work on various projects, these experiences have inspired me to involved in learning of Autosar Testing, Tools and Migration procedures.
AutoSAR Tools
There are tools employed in developing AUTOSAR ECU software. These tools are categorized into the following types;
Tools for system design
Tools, for system design; these help in defining the network architecture, communication & also assist in the design and distribution of software of the software components (SWCs).
Tools for configuration of the software and RTE; Additionally these tools aid, in generating a configuration description of the BSW modules in the Electronic Control Unit (known as ECU Configuration Description).
Code generators for BSW modules; Through code generators that are based on the Electronic Control Unit Configuration Description. produce configured Basic Software (BSW) modules, for the Electronic Control Unit.
These tasks are usually handled by tools. Hence an important aspect of AUTOSAR involves a XML format that can be used as the foundation, for exchanging design & config1uration data b/w tools.
Standardization plays a role because development projects often involve using tools from manufacturers. For instance the microcontroller independent BSW may be provided by one software company while the MCAL and its associated code generators are developed by the semiconductor manufacturer.
In some cases each BSW module might even require a tool. However it is generally recommended to use a tool, for configuring the BSW in scenarios.
AutoSAR Migration Solutions
The AUTOSAR standard enables the migration of ECU software that was not originally developed according to the AUTOSAR method, into the AUTOSAR environment. To facilitate this AUTOSAR provides a Complex Driver, which can be regarded as a type of software component that does not necessitate a formalized description following the SWC template.
This can be perceived as a kind of software component (SWC) that does not necessitate a description using the SWC template.
A Complex Device Driver can directly access the AUTOSAR software without relying on the RTE. This means that, from the applications perspective only the basic software undergoes changes while the application itself can mostly remain unchanged. In the context of migration we can also view the application as a device driver. This can be seen as a step towards an AUTOSAR software architecture, which is considered to be the cost effective approach, in terms of development effort.
By adopting this approach we can already start benefiting from AUTOSAR functionalities. For example we can periodically call upon parts of the application through the RTE. Utilize communication and diagnostics services via the RTE while keeping implementation of our application core AUTOSAR compliant.
In the run we remove the parts of the application that don't adhere to AUTOSAR. Specifically we eliminate all task bodies. Calls, into the operating system well as any points with interrupt blocking and other basic software accesses. We replace them with elements that're compliant with AUTOSAR standards. By using a design approach we can implement these application portions more efficiently, than before.
AUTOSAR ECUs Testing
During the testing phase the same approaches can be applied to AUTOSAR ECUs as those used for Electronic Control Units, with different internal software architectures. When we view the ECU as a box we only need to consider the following aspects;
- Network Management (NM):
AUTOSAR makes use of a Network Management Protocol that differs from hired protocols like OSEK Network Management. In our take a look at surroundings it's far important to remember this NM protocol and make certain that we adequately take care of and process the messages, at the network channels.
- File Formats for Network Communication Description: The System Description includes a description of network connectivity in AUTOSAR. earlier forms such, as.dbc, FIBEX or.ldf (depending on OEM requirements) have been replaced by a format. The test environment should be capable of processing this format.
AUTOSAR gives a software program structure that brings an advantage, for trying out and debugging ECUs. This shape ensures the availability of nation variables in every AUTOSAR Electronic Control Unit, which may be used within the testing surroundings.
For instance the ECU state is available through the EcuM module while communication states of network channels within the ComM module's storage. By implementing BSW modules these state variables can be accessed via an XCP connection to the Electronic Control Unit whether it's through an interface for debugging or one of the networks like JTAG or Nexus. BSW generators can provide an A2L description file that corresponds to these state variables. Alternatively AUTOSAR offers a Monitoring & Debugging protocol specifically designed for this purpose.
AUTOSAR also provides advantages when it comes to accessing the application level. For instance the Runtime Environment (RTE) can be generated in a manner that enables access, to the data, between the SWCs. Additionally the Runtime Environment (RTE) generator can produce an A2L file.
In Conclusion;
AUTOSAR takes an approach to develop ECU software offering tools, for system design, software configuration and code generation. These tools establish a foundation for automotive systems. AUTOSARs migration solutions utilize Device Drivers to integrate existing software into the AUTOSAR environment. The standardized internal software architecture ensures access to state variables, which greatly benefits testing and debugging processes. Overall adopting AUTOSAR not streamlines development processes. Also showcases the automotive industrys commitment to reliability, efficiency and adaptability. This represents an advancement, in the evolution of ECU software.
Top comments (0)