In many block diagrams of AUTOSAR specification they use the term PduR.
But there is no such kind of module in AUTOSAR Schema.
Can someone explain what does PduR mean?
PduR is the abbreviation for “Pdu Router”. The PduR is a basic software module in the AUTOSAR stack.
A typical purpose of the PduR is to accept Pdus from a lower-layer module and deliver it to a higher-level module or vice versa.
The PDU Router module is a central module of the AUTOSAR communication stack. its main purpose is to provide an abstractions from bus-dependent communication modules (CAN , Flexray , ETH , LIN , ....etc) and is responsible for the Routing of I-PDUs from (BUS_if) to com and vise versa ,Routing to/from TP Modules, perform Gateway Functionality
PDUR is a Router of pdu which routes the pdu from lower layer to upper layer and vice versa, pdur lies in service layer of BSW, followed by com.
Related
I'm struggling to understand what is exactly RPC (Remote procedure call), a way of thinking or an actual protocol ?
Is it a concept that promotes a layer of indirection for distributed communication or it is an actual protocol that ships with the OS (unix/windows) and it is used ONLY between some specific services ?
Can RPC be seen as an analogy to OSI model, where it answers to "WHAT" but not to "HOW", therefore it is used just for reference ?
To my understanding, ANY (unidirectional, bidirectional) communication between two processes (local/remote) seems to be what we call "RPC material". Is it correct ?
Thanks
I haven't understood well how to use port, connector and interfaces in a UML2 component Diagram.
I understand that a component can be a physical or a logical component, is the same with interfaces? For example a required import becomes a required interface in component diagram or a simple usage as in class diagram? And also I don't understand the concept of a port as an interaction point: is only a representation of enter and exit point in amicroservice?
To understand I've made two very typical scenarios in applications (I'm a java developer).
Scenario 1
A typical facade pattern where my client application needs to call several web services (rest or soap) through a facade.
I try to represent in a component diagram:
1a) is this diagram correct?
1b) Between Client and facade component is the use of interfaces correct or I only need a simple <>? Phisically ther's no interface, but only a class import, but logically even the facade component expose an API (different from web service API). Port is not needed because client and facade are not pieces of software totally indipendent, am I right?
1c) Between Facade and Services I need ports because we connect to various indipendent pieces of software (maybe not event our software). Is right?
Scenario 2
Now I made a second scenario also very typical in a java web application.
An MVC application that need to call an EJB (a remote class with an interface) for business puroposes.
My component diagram:
2a) In this case a enclosed my userInterfaces in a presentation component a made a delegation connection between various UI and the entire component. Is this the right way to use it?
2b) Between presentation and business component is the same situation of scenario1 when a I call the web services and the use of the port is needed?
If my component diagrams are wrong, please help me understand my errors and how to make a correct component diagrams for those scenarios.
This is almost ok. Your Delegate class looks superfluous. Delegation is a more abstract concept:
(sorry for that pinkish label; tool issue)
So you just draw a <<delegate>> relation from the port towards the class, component or property which inside the component will take responsibility. You can also delegate to internal interfaces as you did.
I looked up UML 2.5 for delegation. On p.189:
A delegation Connector is a Connector that links a Port to a role within the owning EncapsulatedClassifier. It represents the forwarding of requests (Operation invocations and Signals). A request that arrives at a Port that has a delegation Connector to one or more Properties or Ports on Properties will be passed on to those targets for handling.
Delegation Connectors can be used to model the hierarchical decomposition of behavior, where services provided by an EncapsulatedClassifier may ultimately be realized by one that is nested multiple levels deep within it.
As a ConnectableElement, the effective provided Interfaces (see 11.2.3) of a Port are its provided interfaces, and the effective required Interfaces are its required Interfaces. However, for a delegating Port, i.e., a Port that is at an end of a delegation Connector and is not on a role and that is not a behavior Port, the effective provided Interfaces are its required interfaces and its effective required Interfaces are its provided interfaces. Consequently a delegating Port behaves, for connection, as though it had an internal “face” that is the conjugate of its external “face.”
If several Connectors are attached on one side of a Port, then any request arriving at this Port on a link derived from a Connector on the other side of the Port will be forwarded on links corresponding to these Connectors. It is not defined whether these requests will be forwarded on all links, or on only one of those links.
There's more about ports around that page.
I know that IRepository has to put in domain folder, but for the rest of the interfaces such as: IQueryBus, ICommandBus... should I put them in Application folder?
I've seen a lot examples where some of them put this kind of interfaces in domain like /domain/bus/IQueryBus, /domain/bus/ICommandBus and other put them in /application/bus/IQueryBus /application/bus/ICommandBus. I'm not sure what is the best option and why. Also I've read this article https://herbertograca.com/2017/11/16/explicit-architecture-01-ddd-hexagonal-onion-clean-cqrs-how-i-put-it-all-together/ that explain: It’s important to note that the Ports (Interfaces) belong inside the business logic, while the adapters belong outside. so, if I understood very well all interfaces have to put in domain folder?
First of all , we have to distinguish the aspect of the port:
Driver ports (primary ports). They are interfaces offering the use cases of our application. So they belong to the application layer. They are called by the driver adapters and they are implemented by the application layer.
Driven ports (secondary ports). Here it depends. A driven port is an abstraction (interface) for doing some task that is performed by an external actor outside your application. If such task is logic that is independent of whatever domain, then the port interface belongs to the application layer (for example a port for authentication and authorization). If the tasks are logic of the domain of your application, then the port belongs to the domain.
I will refer to the word context as a space that can be a package or a folder or whatever container you can use to separate concepts.
You should put each interface in the context determined by its purpose.
Generic interfaces like ICommandBus can be put inside an "infrastructure" context, the interfaces offering domain behavior inside the domain context, if inside it you have a more specific context inside the domain context use that one.
That kind of interfaces are like bridges between contexts, so, each context has its own interfaces offering functionalities implemented in a different context.
I'm new in AUTOSAR, I'm working on a project and my only concern is modeling (Software Components layer), without Basic Software implementation. I'm looking for a way to specify crypto information in the model (a way to specify that a specific communication has to be treated by the Crypto Service Manager). Does someone know a way to do so? Any tips or advice would be accepted.
The principle is same as with other services, model a SwcServiceDependency that aggregates a CryptoServiceNeeds. Create RoleBasedPortAssignments to indicated which PortPrototypes shall be used to interact with the Csm.
The SWC defines a way to specify the Crypto Service Needs of an SWC. This is defined in the standard/AUTOSAR_TPS_SoftwareComponentTemplate.pdf
But the actual sighing and authentication is done in the BSW by first routing incoming SecuredIPdus by the PduR to the SecOC, which will forward authentication to the CryptoStack (Csm, Cry, CryIf, CAL / CrySHE). They'll return an (authenticated) IPdu back to the PduR, which routes it up to Com, which provides you the ISignalGroups and ISignals. To transmission is just the opposite way, where the SecOC gets an IPdu and delivers back a SecuredIPdu, which is routed by PduR down to the If to the -Driver to transmit.
On the receiving side, failed authentication will, the same as other failures usually cause the IPdu to be discared to higher layers, which looks like a message was never received.
This BasicSW parts are defined in the SystemDescription, which is defined in the standard/AUTOSAR_TPS_SystemTemplate.pdf
Im new to zmq. Im using the same for local IPC in a Linux based OS (The socket is AF_UNIX type)
But I could not find a way to get the caller's (client) process Id. Is there any way to find the same using zmq ? (Finding the pid of the caller is must for my access control requirement and if zmq does not provide the same then I should switch to dbus)
Please help me.
Forget most of the low-level socket designs and worries. Think higher in the sky. ZeroMQ is a pretty higher-level messaging concept. So you will have zero-worries about most of the socket-io problems.
For more on these ZMQ principles, read Pieter Hintjens' design maxims and his resources-rich book "Code Connected, Vol.1".
That said, the solution is fully in your control.
Solution
Create a problem-specific multi-zmq-socket / multi-zmq-pattern (multiple zmq-primitives used and orchestrated by your application level logic) as a problem-specific formal communication handshaking.
Ensure the <sender> adds it's own PID into message.
Re/authorise via another register/auth-socket-pattern with the pre-registered sender from the receiver side, so as to avoid a spoofed attack under a fake/stolen PID-identity.
Adapt your access-control policy according to your ProblemDOMAIN, use and implement any level of crypto-security formal handshaking protocols for identity-validation or key-exchange, to raise your access-control policy security to adequate strengths ( including MIL-STD grades ).