Search code examples
autosar

Autosar basic software modules interaction


I am reading this AUTOSAR documents, and it says that the communication of the software components with each other and the communication of the SWCs with BSW is realized via RTE Layer, but I did not find any information about the implementation of the interactions between basic software modules with each other, for example, the interaction between ECU AL layer and MCAL Layer.
There are 3 types of interfaces according to AUTOSAR. They are : "autosar interface", "standardized autosar interface" and" standardized interface".
The "autosar interface" is used to define the ports for SWCs. Then there is "standardized autosar interface" type, which is used to define SERVICE ports for SWCs. These two types both are used for SWCs and both models the communication mechanism using ports, but the "standardized interface" do NOT use the same technique as "autosar interface".
I mean that probably the "standardized interface" contract do NOT use PORTS to define the communication between BSW modules and I want to know that if there are no ports for BswMs, then how do they communicate? Are the communication mechanisms modeled in those modules themselves?
1. Do the BSW Modules have ports?
2. Does RTE define the communication between MCAL Layer & ECU Abstraction layer?if not, then in which part of the code it should be implemented?


Solution

  • 1.) Ports are the preferred way of interface definition on software component's level. The "standardized intefaces" are SwC ports that give access to underlying BsW module functionality. They are categorized as service-ports and their components are typically bound to an ECU. Vendors exposing BSw module functionality to other SwC-s by their custom SwC is breaking the layered architecture and it is considered bad practice. (Thank you Uwe for pointing that out in the comments)

    2.) On a module's level interfaces are header files with certain function declarations in them. Inter-BSwM communication is not RTE's task by design. Also, boot sequence is bottom up; it could happen RTE is not even booted yet for BSwM-s to use.

    Think of ports as a logical feature. Based on their type you have some freedom in modelling them. When you generate the RTE these ports are realized (or in other words boil-down) to a certain solution: writing a buffer or as simple as a C function call. This abstraction even enables you to re-allocate your SwCs to another AUTOSAR ECU and the ports will still function.

    You do not have this much freedom in BSwMs; their communicaton is more concrete, with C function calls. BSwMs can be optionally modelled in AUTOSAR: their interfaces as well as their internal behaviour. But unlike in SwC, such models are not having a direct effect on the implementation. They are rather for documenting, writing tests or compliance checks.