Autosar基础软件模块交互
我正在阅读这个AUTOSAR文档，它说软件组件之间的通信以及SWC与BSW的通信是通过RTE层实现的，但是我没有找到任何关于基础软件之间交互的实现的信息模块之间的交互，例如ECU AL层和MCAL层之间的交互。
根据 AUTOSAR，有 3 种类型的接口。它们是：“autosar 接口”、“标准化 autosar 接口”和“标准化接口”。
“autosar 接口”用于定义 SWC 的端口。然后是“标准化autosar接口”类型，用于定义SWC的SERVICE端口。这两种类型都用于 SWC，并且都使用端口对通信机制进行建模，但“标准化接口”不使用与“autosar 接口”相同的技术。
我的意思是，“标准化接口”合同可能不使用PORTS来定义BSW模块之间的通信，我想知道如果没有BswMs的端口，那么它们如何通信？通信机制是否在这些模块本身中建模？
1. BSW 模块有端口吗？
2. RTE 是否定义了 MCAL 层与 MCAL 层之间的通信？ ECU抽象层？如果没有，那么应该在哪部分代码中实现？
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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
1.) 端口是软件组件级别上接口定义的首选方式。 “标准化接口”是 SwC 端口，可以访问底层 BSW 模块功能。它们被归类为服务端口，其组件通常绑定到 ECU。
供应商通过其自定义 SwC 将 BSw 模块功能暴露给其他 SwC-s 破坏了分层架构，这被认为是不好的做法。 （感谢 Uwe 在评论中指出这一点）
2.）在模块级别的接口上，头文件中包含某些函数声明。 BSwM 间通信并不是 RTE 设计的任务。另外，启动顺序是自下而上的；可能会发生 RTE 甚至尚未启动供 BSwM-s 使用的情况。
将端口视为逻辑功能。根据它们的类型，您可以自由地对它们进行建模。当您生成 RTE 时，这些端口将实现（或者换句话说，归结为）某种解决方案：写入缓冲区或像 C 函数调用一样简单。这种抽象甚至使您能够将 SwC 重新分配给另一个 AUTOSAR ECU，并且端口仍然可以工作。
在 BSwM 中你没有这么大的自由度；他们的通信更加具体，通过 C 函数调用。 BSwM 可以选择在 AUTOSAR 中建模：它们的接口以及它们的内部行为。但与 SwC 不同的是，此类模型不会对实施产生直接影响。它们更适合记录、编写测试或合规性检查。
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.