Permet aux applications de valider des jetons SOVD ainsi que de fournir des URL d’autorisation et de jeton.
GÉNÉRÉ PAR IAnon vérifiéModèle : gemini-3.8-flash-medium · Effort : medium · Température : non réglable · Prompt : 49d1f84283f8ProvenanceQuestions ouvertes (2)
traduit du guide allemandgemini-3.8-flash-low · 2026-10-13 · Original allemand
Permet aux applications de valider des jetons SOVD ainsi que de fournir des URL d’autorisation et de jeton.
La classe ara::diag::SovdAuthorization sert aux applications pour implémenter les interfaces d’autorisation SOVD vis-à-vis du Diagnostic Server ([SWS_DM_01490]). Elle fournit des méthodes pour déterminer les URL de redirection pour les points de terminaison d’autorisation et de jeton ainsi que pour vérifier les jetons d’accès ([SWS_DM_01483]). La réception des messages doit être explicitement activée avec Offer() après l’instanciation, et l’objet d’authentification transmis ne doit plus être utilisé après la fourniture du résultat de validation.
Contexte
La classe ara::diag::SovdAuthorization met à disposition l'interface d'application adaptative afin de fournir des mécanismes d'autorisation et d'authentification pour Service-Oriented Vehicle Diagnostics (SOVD) ([SWS_DM_01490]). Au sein de l'architecture de diagnostic, elle sert d'intermédiaire entre le Diagnostic Server du Diagnostic Management (DM) et la logique d'autorisation individuelle de l'application du véhicule (SWS Diagnostics §7.3.3.2 « SOVD Request Validation and Verification »). Lorsqu'un client SOVD externe interroge des points de terminaison pour la vérification de client ou la récupération de jetons, le Diagnostic Server transmet ces requêtes à l'application afin de déterminer les URL cibles ([SWS_DM_01471], [SWS_DM_01472]). Lors de requêtes de diagnostic entrantes comportant un en-tête d'autorisation HTTP, la classe vérifie la validité du jeton et définit les rôles d'accès transmis ([SWS_DM_01470]). La validation effective auprès d'un serveur d'autorisation (tel qu'OAuth 2.0) devrait s'effectuer sous forme d'interprétation spécifique à l'application via des protocoles réseau externes, dans la mesure où AUTOSAR standardise ici le point de transmission applicatif local. Question Q-6ce702103e4966c7 (ouverte)
L’instanciation de ara::diag::SovdAuthorization s’effectue explicitement via le constructeur en indiquant un ara::core::InstanceSpecifier ainsi que le mode de concurrence ConcurrencyType ([SWS_DM_01489]). Le InstanceSpecifier doit faire référence dans le manifeste à un PortPrototype valide d’un DiagnosticSovdAuthorizationInterface. Le ConcurrencyType (kConcurrent ou kNotConcurrent) détermine si les méthodes de rappel implémentées de l’application doivent être conçues pour être sûres pour les threads ([SWS_DM_01483], [SWS_DM_01484], [SWS_DM_01485]).
Après la construction, le Diagnostic Server ne transmet les requêtes que lorsque l’application a appelé avec succès la méthode Offer() ([SWS_DM_01487]). Interprétation : les requêtes arrivant avant le Offer() sont probablement rejetées par le serveur ou refusées avec une erreur. Question Q-84330742a61f91a7 (ouverte) Pour mettre fin au transfert des requêtes, l’application appelle StopOffer() ([SWS_DM_01486]). Enfin, l’objet est libéré via le destructeur virtuel ([SWS_DM_01488]). Les appels administratifs SovdAuthorization, Offer, StopOffer et le destructeur ne sont pas sûrs pour les threads.
Parcours d'utilisation
En cours de fonctionnement, deux chemins d’interaction principaux apparaissent : la fourniture d’URL de redirection et la validation de jetons de session actifs. Si un client SOVD envoie une requête de vérification de client ou de demande de jeton, le DM appelle GetAuthorizationUrl() ([SWS_DM_01485]) ou GetTokenUrl() ([SWS_DM_01484]). L’application évalue les queryParameters transmis ainsi que la metaInfo et renvoie l’URL cible de manière asynchrone sous la forme ara::core::Future<ara::core::String>, à la suite de quoi le DM répond avec un HTTP 307 (Temporary Redirect) ([SWS_DM_01471], [SWS_DM_01472]).
Si une requête SOVD ultérieure contient un en-tête HTTP Authorization nouveau ou modifié, le Diagnostic Server appelle ValidateAuthorization() ([SWS_DM_01470], [SWS_DM_01483]). L’application valide le token transmis, attribue à l’objet référencé ara::diag::ClientAuthentication les rôles d’autorisation correspondants ([SWS_DM_01469]) et renvoie un ValidateAuthorizationOutput via le Future. Condition préalable importante : dès que le Future est disponible, l’application ne doit plus utiliser l’objet ClientAuthentication référencé ([SWS_DM_01483]). Le DM utilise les valeurs de retour (durée de validité validUntil et identity) pour associer les requêtes ultérieures du même client sans nouveau contrôle ([SWS_DM_01781], [SWS_DM_01782]), ce qui est notamment requis pour les verrouillages de ressources SOVD ([SWS_DM_01783]).
Les erreurs sont représentées via ara::core::Result ou au sein du ara::core::Future renvoyé :
Erreurs d’initialisation et de modélisation : si l’instanciation échoue, des violations sont signalées, par exemple InstanceSpecifierMappingIntegrityViolation (élément de modèle invalide), PortInterfaceMappingViolation (type d’interface incorrect), ProcessMappingViolation (référence de processus manquante) ou InstanceSpecifierAlreadyInUseViolation ([SWS_DM_01489]).
Erreurs de libération lors de l’offre : en cas d’erreur, Offer() renvoie DiagOfferErrc::kAlreadyOffered si le service est déjà actif, ou DiagOfferErrc::kConfigurationMismatch si la configuration ne correspond pas aux données DEXT ([SWS_DM_01487]).
Erreurs lors de la validation du jeton : si un jeton ne peut pas être vérifié, ValidateAuthorization() fournit via le Future DiagSovdErrc::kInvalidAccessToken (jeton invalide) ou DiagSovdErrc::kTemporarilyNotAvailable (par ex. si le serveur d’authentification n’est pas accessible pour la vérification en ligne) ([SWS_DM_01483]).
Détermination d’URL : aucun code d’erreur standardisé n’est défini pour GetAuthorizationUrl() et GetTokenUrl() ([SWS_DM_01484], [SWS_DM_01485]).
Ce guide repose exclusivement sur les spécifications de la version AUTOSAR R25-11.
Get the URL that the SOVD client shall use for authorization. The SOVD client will be redirected to that URL. If OAuth 2.0 is used, this would be the URL to look up the Authorization Server’s authorize endpoint.
Get the URL that the SOVD client shall use to request a token. The SOVD client will be redirected to that URL. If OAuth 2.0 is used, this would be the URL to look up the Authorization Server’s token endpoint.
This function validates the authorization token sent by the SOVD client. The application shall validate the authorization token according to the authorization protocol used in the system and then according to the outcome set the respective roles as authorized in the clientAuthentication that is passed as parameter. If OAuth 2.0 is used, this would implement the validation that is supposed to happen in the Resource Server.
Get the URL that the SOVD client shall use for authorization. The SOVD client will be redirected to that URL. If OAuth 2.0 is used, this would be the URL to look up the Authorization Server’s authorize endpoint.
Get the URL that the SOVD client shall use to request a token. The SOVD client will be redirected to that URL. If OAuth 2.0 is used, this would be the URL to look up the Authorization Server’s token endpoint.
This Offer will enable the DM to forward request messages to this handler.
GÉNÉRÉ PAR IAnon vérifiéModèle : gemini-3.8-flash-medium · Effort : medium · Température : non réglable · Prompt : 0834519262c7Provenance
traduit du guide allemandgemini-3.8-flash-low · 2026-10-13 · Original allemand
La fonction membre synchrone Offer de la classe ara::diag::SovdAuthorization active le routage des messages de requête par le Diagnostic Management (DM) vers l’instance de handler associée [SWS_DM_01487]. Elle ne prend aucun paramètre et renvoie un ara::core::Result<void> confirmant le succès de l’appel ou signalant une erreur survenue [SWS_DM_01487].
En ce qui concerne le traitement des erreurs, [SWS_DM_01487] spécifie deux codes d’erreur concrets issus de DiagOfferErrc avec une sémantique de rollback :
DiagOfferErrc::kAlreadyOffered : survient lorsque le service est déjà proposé pour cette instance [SWS_DM_01487].
DiagOfferErrc::kConfigurationMismatch : signale que la configuration ne correspond pas aux données de description DEXT [SWS_DM_01487].
Concernant les propriétés d’exécution, l’appel est déclaré sûr vis-à-vis des exceptions (exception safe), mais est considéré comme non sécurisé pour les threads (not thread-safe) [SWS_DM_01487]. La fonction ne doit donc pas être appelée de manière concurrente pour la même instance.
En interaction avec le DM, la fonction correspond au modèle général de mise à disposition des interfaces de diagnostic AUTOSAR Adaptive, tel qu’il est également employé pour les routines génériques ou les services DoIP (par exemple [SWS_DM_00557], [SWS_DM_00725] ou [SWS_DM_00809]). Tant qu’un handler n’a pas été enregistré via Offer, le DM ne transmet pas les requêtes à l’application ou les traite avec des valeurs de substitution prédéfinies [SWS_DM_01487], [SWS_DM_01525], [SWS_DM_01527].
Ce texte a été généré par une IA. Toutes les informations reposent exclusivement sur l’extrait de spécification fourni.
InstanceSpeci- InstanceSpecifier either cannot be resolved in the model in the fierMappingIn- context of your executable, or it refers to a model element other tegrityViolation than a PortPrototype. PortInterfaceMap- A PortPrototype that is referenced by a pingViolation DiagnosticSovdAuthorizationPortMapping needs to be typed by a DiagnosticSovdAuthorizationInterface. ProcessMappingVio- Matching InstanceRef exists, but no matching (modelled) Process lation found that matches the (runtime) process. InstanceSpecifier- Violation message that is sent in case a constructor in the ara AlreadyInUseViola- framework was called with an InstanceSpecifier already in use in tion this process.
Parameter (in)
Parameter
Beschreibung
instanceSpecifier
InstanceSpecifier to a PortPrototype of a DiagnosticSovdAuthorizationInterface service instance in the manifest.
concurrencyType
Specifies if the interface is implemented as thread safe ( kConcurrent) or non-thread safe (kNotConcurrent).
Request a governed re-review of this record. The record is not changed immediately.
This StopOffer will disable the forwarding of request messages from DM.
GÉNÉRÉ PAR IAnon vérifiéModèle : gemini-3.8-flash-medium · Effort : medium · Température : non réglable · Prompt : c318a30e32adProvenanceQuestions ouvertes (1)
traduit du guide allemandgemini-3.8-flash-low · 2026-10-13 · Original allemand
Utilisation
La méthode StopOffer de la classe ara::diag::SovdAuthorization (en-tête ara/diag/sovd_authorization.h) sert à interrompre le routage des requêtes de diagnostic entrantes provenant du Diagnostic Management (DM) vers le service d’autorisation [SWS_DM_01486]. La fonction possède la signature void StopOffer() noexcept. Elle n’accepte aucun paramètre et ne renvoie aucune valeur de retour à l’appelant [SWS_DM_01486].
Gestion des erreurs et concurrence
La fonction est spécifiée comme sûre vis-à-vis des exceptions (exception safe) et ne lève aucune exception [SWS_DM_01486]. Aucun code d’erreur spécifique ni message d’erreur vers DET ou DEM n’est prévu pour cet appel. Concernant la concurrence, la méthode est classée comme non sécurisée pour les threads (not thread-safe) [SWS_DM_01486]. Si plusieurs threads utilisent le même contexte d’instance, l’accès doit être synchronisé par l’application appelante. Interprétation : un appel devrait surtout intervenir lors de l’arrêt ordonné de l’application ou en cas de suspension temporaire de la disponibilité d’autorisation. Question Q-6c81f2dc7ee903ca (ouverte)
Interaction
Le concept suit le patron de conception général des interfaces dans le diagnostic AUTOSAR Adaptive : la désignation StopOffer a été choisie par analogie avec les interfaces de service de ara::com, mais représente une implémentation autonome au sein de ara::diagAUTOSAR_AP_SWS_Diagnostics §7.3.4.1.2 « Monitors ». La même sémantique de désactivation se retrouve à l’échelle du module dans de nombreuses autres interfaces de port, par exemple pour GenericRoutine[SWS_DM_00558], Authentication[SWS_DM_01131], CommunicationControl[SWS_DM_00810] ainsi que Monitor[SWS_DM_01089].
Cette note d'utilisation a été générée de manière automatisée à partir de la spécification AUTOSAR AP R25-11.
This function validates the authorization token sent by the SOVD client. The application shall validate the authorization token according to the authorization protocol used in the system and then according to the outcome set the respective roles as authorized in the clientAuthentication that is passed as parameter. If OAuth 2.0 is used, this would implement the validation that is supposed to happen in the Resource Server.
GÉNÉRÉ PAR IAnon vérifiéModèle : gemini-3.8-flash-medium · Effort : medium · Température : non réglable · Prompt : 78d8310937f8Provenance
traduit du guide allemandgemini-3.8-flash-low · 2026-10-13 · Original allemand
La méthode purement virtuelle ValidateAuthorization est appelée par le serveur de diagnostic lorsqu'une requête d'un client SOVD contient un en-tête HTTP Authorization et que son jeton n'est pas encore validé [SWS_DM_01470]. L'application vérifie le jeton d'autorisation transmis selon le protocole configuré dans le système (par exemple OAuth 2.0 dans le contexte d'un Resource Server) et affecte les rôles correspondants au client [SWS_DM_01483].
token (ara::core::StringView) : le jeton d'accès transmis depuis l'en-tête HTTP [SWS_DM_01483].
metaInfo (const MetaInfo&) : métadonnées du port de service de diagnostic [SWS_DM_01483].
clientAuthentication (ClientAuthentication&) : objet par le biais duquel l'application définit les rôles authentifiés du client SOVD [SWS_DM_01483]. Après la mise à disposition du Future renvoyé, l'application ne doit plus utiliser cette référence [SWS_DM_01483].
Valeur de retour : un ara::core::Future<ValidateAuthorizationOutput>[SWS_DM_01483]. En cas de validation réussie, la structure ValidateAuthorizationOutput[SWS_DM_01927] contient l'horodatage de validité validUntil[SWS_DM_01820] ainsi que l'identifiant du client identity[SWS_DM_01819].
Le Diagnostic Server considère les rôles affectés comme authentifiés pour les requêtes avec un jeton identique jusqu'à atteindre validUntil[SWS_DM_01469] et reconnaît le client SOVD à l'aide du jeton ou de l'identité [SWS_DM_01781][SWS_DM_01782]. Cette reconnaissance est notamment requise pour les opérations temporaires et les verrous SOVD, car l'accès de verrouillage est refusé aux clients non authentifiés avec HTTP 401 [SWS_DM_01783].
En cas d'erreur, le Future est résolu avec DiagSovdErrc::kInvalidAccessToken (jeton non valide) ou DiagSovdErrc::kTemporarilyNotAvailable (p. ex. serveur d'authentification temporairement inaccessible) [SWS_DM_01483]. La fonction est spécifiée comme noexcept et sûre vis-à-vis des exceptions ; le fait que l'implémentation doive être thread-safe est contrôlé via le ConcurrencyType transmis dans le constructeur [SWS_DM_01483].
Cette note d'utilisation a été générée par une IA ; seule la spécification AUTOSAR fait foi.
conditional whether the function has to be implemented thread safe or non-thread safe is determined by the ConcurrencyType given in the constructor
Parameter (in)
Parameter
Beschreibung
token
The authorization token sent by the SOVD client in the HTTP Authorization header.
metaInfo
The meta information of a diagnostic service port.
clientAuthentication
Object used by the application to report the authenticated state of the SOVD client. After the returned Future is ready, the referenced object shall not be used any more by the application.
rollback_semantics The request currently can’t be served, e.g. in case the access token currently can’t be verified (e.g. because online verification is needed and the authentication server can’t be reached).
Request a governed re-review of this record. The record is not changed immediately.
gemini-3.8-flash-low· 2026-10-13 · Original allemand