2

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.

damaar
  • 171
  • 1
  • 2
  • 11

2 Answers2

1

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.

Uwe Honekamp
  • 2,478
  • 1
  • 17
  • 15
  • Thank you for your answer, can you link me a guide or something to learn how to model this kind of services? Or even a suggestion of where to look for (for example autosar standard or something related). – damaar Jan 28 '16 at 09:41
  • I found a way to protect data integrity on the standard (through the use of E2EProtection), but not a way to cipher them (My concern is still modeling, not implementing). – damaar Jan 28 '16 at 09:43
  • 1
    The details are explained in the Specification of the AUTOSAR Software Component Template. This document all contains examples of how to model SwcServiceDependencies for specific service use cases. – Uwe Honekamp Jan 29 '16 at 17:46
  • Thank you very much! The documentation is huge, so just knowing the correct section is a very useful information! – damaar Jan 29 '16 at 18:07
0

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

kesselhaus
  • 1,241
  • 8
  • 9