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?
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.
Related
Is it generally possible to access a shareable interface of an applet installed in a different Security Domain in a card compliant to both Java Card and Global Platform specifications?
If this is not possible, is there another way of invoking applications in another Security Domain, potentially by manually communicating via Secure Channels?
From the JavaCard Runtime Environment spec, Shareable Interfaces (6.2.4) :
Shareable interfaces are a feature in the Java Card API to enable applet interaction. A shareable interface defines a set of shared interface methods. These interface
methods can be invoked from one context even if the object implementing them is
owned by an applet in another context.
The applet firewall of the Java Card world divides between contexts(6.1.2), the ShareableInterfaceObject is spefically designed to enable interaction between contexts that would otherwise be forbidden.
The concept of Security Domains originates from the Global Platform specifications and is not present in the JavaCard specification. Searching the term in the JavaCard documentation will actually yield no results. As these things don't have anything in common, there should not be a problem with your setup.
What is the main motive of introducing Adaptive Autosar?
Information provided by Autosar consortium is "AP provides mainly high-performance computing and communication mechanisms and offers flexible software configuration."
High performance computing will be achieved through many/multi core processors,
Ethernet will be used for communication
Application will be programmed in C++ language and POSIX will be used.
My doubts are :
Multi core is already used in Classic platform
Since Autosar is completely Software, how usages on many core FPGA etc will be considered in autosar scope.
Ethernet is also available for Classic Platform.
How C++ fulfill the motive of flexibility, security and high computation?
What is contribution of POSIX in Adaptive autosar?
Classic AUTOSAR (especially AUTOSAR OS) is based on static configuration of OS objects like e.g. tasks (mainly because of and through the largely OSEK-like OS; simply said, AUTOSAR OS is OSEK++).
Main point of adaptive AUTOSAR will be to change that concept, introducing dynamically creatable OS objects. Imagine that an adaptive AUTOSAR system would allow to load executables which were unknown at built time.
(Not discussing here whether that is a safe/secure design.)
See my answer :
Multi core is already used in Classic platform
Yes but it is uC core and the performance.. capability is completely different with uP core i.e some state of the art uP core A53, A57 based.
Why.. uP designed for High Performance Applications.
uC hard to render a HD videos ... but uP does.
Since Autosar is completely Software, how usages on many core FPGA etc will be considered in autosar scope.
Autosar do not only refer to Software but it turns out Hardware requirements as following.
Eg. You could not port a POSIX OS compliant to uC
FPGA can be configure as a SoC for that you can even have a uC and uP running on same board. The rest is free to use.. Autosar Classic in uC and Autosar Adaptive in uP.
Ethernet is also available for Classic Platform.
Autosar Adaptive not even defined what is communication protocol
it just say ara::com following with many Spec and Requirement.. that make vendor or Autosar Provider can implement COM in various way... regards Service Oriented motivations.
How C++ fulfill the motive of flexibility, security and high computation?
It is hard to explain all in one here...
But to fulfill it, we need a completely new platform supports(called Foundations in Adaptive)
Eg. To handle safety we will not start an application via systemd(Linux) or Init (Android) but we need completely new Function to do it : Execution Manager - Adaptive Autosar.
What is contribution of POSIX in Adaptive autosar?
It only related to OS requirement, where at least some "system API" need to be support by OS. The list of system API you can find in POSIX PSE 51.
I am developing a software in Java which will run a TFTP Client created as a part of the software and will connect to a TFTP Server which will be external.
My question is should I have the TFTP Client as an actor inside the system boundary using the Actor symbol, as this is something that the system will do? or should I leave it outside the system boundary?
Actors are by definition the things outside of your system with which your system interacts.
So an Actor inside your system boundary would be a contradictio in terminis
It depends on your abstraction level. It is well possible to define actors inside the system under consideration which you represent as the main boundary. Usually if you introduce such actors inside it means that you have sub-systems where those actors interact. So in your case the TFTP is such a sub-system.
I wanted to know whether is it possible to make use of COM component in other platforms like linux,etc..,
My question is that COM component is supposed to be registered with OS &
For that OS need something like registry so that client can use COM components.
Can anyone shed light on my question ?
If you want to have the ability to create COM classes by specifying a "string", and wish the OS can search for the correct binary library to load from as well as creating the actual COM class (object), then some form of registering is needed.
Other than that, if you only want to use COM-style interfaces (interfaces derived from IUnknown, IDispatch, etc) you can do that in any C++ languages (as long as the vtable implementation of that C++ compiler is compatible with COM).
Finally, some COM capabilities such as inter-process communication and remote invocation are provided as part of Windows OS. You will need to implement your own if these capabilities are needed.
The Wikipedia page on CORBA appears to have some references to a number of choices. Check the See Also section.
The wikipedia entry for Microsoft COM says in the "Overview" that "the interface standard has been implemented on several platforms", but fails to specify which ones. If you're looking for a cross-platform approach, you may be better off with something like XPCOM instead.
Technically speaking, COM is just an architecture that can be implemented in any platform. Looking up registered classes in the registry, for example, is something you could implement in an equivalent way on any other platform. The rest of it is about DLLs and MIDL, which you can get working on any platform.
Practically speaking, COM is for Windows (and even that's dying pretty quickly).
The theoretical answer is yes, it's possible to use COM components on other platforms.
Here's an article from way back in 1998 on Building COM Components on UNIX. However, even back in the day this was not a popular (or prudent!) approach.
I need to expose certain monitoring statistics from my application and I'm wondering what the most widespread framework or protocol is for doing this?
SNMP is widely used and a standard protocol. It's implemented in computers, routers, hubs, printers and practically anything connected to the net. Although it's called the SImple Network Management Protocol it's not restricted to network management.
It's an open standard and consequently there are a huge array of management/monitoring solutions, from simple shell scripts and libraries up to enterprise monitoring suites (e.g. HP Openview).
You can query synchronously for data or receive events (in SNMP-speak, traps). Each device will report a common set of data (relating mainly to the network status of that device) plus enterprise-specific data (e.g. CPU usage, printer status etc.).
It runs over UDP, and message consistency is a responsibility of the implementing library. This is a little unusual, but it's designed to operate even when the network is not functioning correctly (e.g. flooded with traffic/misconfigured etc.) and decisions about retry strategies, timeouts etc. need to be taken at the application level (unlike TCP).