Définir l'architecture du service

L'architecture de service fait référence à la façon dont les services sont composés et à la manière dont ils communiquent avec d'autres composants du système.

Créer des groupes de services

Les groupes de services regroupent des unités de service associées qui peuvent être déployées ensemble. La seule propriété requise pour un groupe de services est un nom. Avec le nom du package, le nom forme le nom complet du groupe de services.

Les groupes de services sont définis avec des fichiers VSIDL (Vehicle Services Interface Definition Language, fichiers avec l'extension .vsidl).

L'exemple suivant montre deux groupes de services : un groupe de services TirePressureMonitoring et un groupe de services BodyControl :

package: "com.android.sdv.sample.vsidl"

service_bundle {
  name: "TirePressureMonitoring"
}

service_bundle {
  name: "BodyControl"
}

Où :

  • service_bundle identifie la structure comme un groupe de services.
  • name est le nom du groupe de services.

Modèles de messagerie : Pub/Sub et RPC

Le framework SDV utilise deux modèles de messagerie principaux : Publish-Subscribe (Pub/Sub) et l'appel de procédure à distance (RPC).

Dans Pub/Sub, le système réagit à l'évolution de l'état du véhicule en diffusant des données à tous les composants intéressés. Les données sont organisées en sujets. Les éditeurs envoient des messages sur des sujets. L'éditeur envoie des messages sur des sujets sans avoir besoin de savoir quels abonnés (ou combien) sont à l'écoute. Les abonnés reçoivent des messages sur des sujets sans savoir quels éditeurs exacts ont envoyé les messages.

En revanche, RPC est conçu pour l'action et le résultat. Il est utilisé lorsque l'appelant lance une requête, car il se soucie du résultat spécifique ou de la confirmation de cette action. L'appelant appelle une méthode spécifique sur un canal.

Bien que ces modèles répondent à des besoins opérationnels différents, ils partagent une propriété structurelle commune : ils s'appuient tous deux sur des chemins de communication nommés (sujets pour Pub/Sub et canaux pour RPC) afin de dissocier l'identité de l'expéditeur de celle du destinataire.

Déclarer l'éditeur et l'abonné

Publish-Subscribe est un modèle de messagerie dans lequel les expéditeurs de messages, appelés éditeurs, n'envoient pas les messages directement à des destinataires spécifiques, appelés abonnés. Au lieu de cela, les éditeurs classent les messages en sujets , et les abonnés s'abonnent à un ou plusieurs sujets de communication et ne reçoivent que les messages publiés dans ces sujets. Pour en savoir plus sur Publish-Subscribe, consultez Modèle Publish-Subscribe.

Ajouter un éditeur à un groupe de services

L'exemple suivant montre un éditeur ajouté au groupe de services TirePressureMonitoring :

package: "com.android.sdv.sample.vsidl"

service_bundle {
  name: "TirePressureMonitoring"

  publisher {
    message: "TirePressure"
    topic: "front-left"
    capacity: 10
  }

}

service_bundle {
  name: "BodyControl"

  ...
}

Où :

  • publisher Le message de service publie des messages dans une file d'attente de messages.
  • message Structure de données ou type de message défini dans protobuf (fichier avec l'extension .protobuf).
  • topic Identifiant unique du sujet de publication. Il doit être en minuscules et au format "kebab case".
  • capacity Nombre de messages que la file d'attente de publication peut contenir. Il doit s'agir d'un nombre pair supérieur ou égal à 2.

Ajouter un abonnement à un groupe de services

L'exemple suivant montre un éditeur ajouté au groupe de services BodyControl :

package: "com.android.sdv.sample.vsidl"

service_bundle {
  name: "TirePressureMonitoring"

  publisher {
    message: "TirePressure"
    topic: "front-left"
    capacity: 10
  }
}

service_bundle {
  name: "BodyControl"

  subscriber {
    message: "com.android.sdv.sample.vsidl.TirePressure"
    topic: "front-left"
  }
}

Où :

  • subscriber Le groupe de services s'abonne à des sujets.
  • message Structure de données ou type de message défini dans protobuf (fichier avec l'extension .protobuf).
  • topic Identifiant unique du sujet de publication. Il doit correspondre au sujet de l'éditeur et être en minuscules et au format "kebab case".

Définir des clients et des serveurs RPC

L'appel de procédure à distance (RPC) offre une indépendance de l'emplacement des appels de fonction. Dans ce modèle, le canal sert de point de rendez-vous nommé où le client et le fournisseur se rencontrent. En ciblant le canal plutôt qu'une instance de service spécifique, le framework dissocie l'intention de la commande de l'emplacement physique de l'implémentation.

Dans l'exemple suivant, le groupe de services CabinComfort héberge un serveur ClimateControl, et le groupe de services BodyControl est étendu pour héberger un client ClimateControl :

package: "com.sdv.cc"

service_bundle {
  name: "CabinComfort"

  server {
    service: "ClimateControl"
    channel: "front-climate-control"
  }
}

service_bundle {
  name: "BodyControl"

  client {
    service: "ClimateControl"
    channel: "front-climate-control"
  }

  subscriber {
    message: "com.android.sdv.sample.vsidl.TirePressure"
    topic: "front-left"
  }
}

Où :

  • server indique que le groupe de services contient un serveur qui fournit un service RPC (identifié par service comme ClimateControl).
  • client indique que le groupe de services contient un client qui appelle le service ClimateControl.
  • channel est le nom du canal RPC. Il doit être en minuscules et au format "kebab case", et unique par service.

Cet exemple permet au groupe de services BodyControl d'effectuer des appels de procédure à distance vers le groupe de services CabinComfort pour contrôler la température de la zone avant de l'habitacle.

Étape suivante

Après avoir défini votre architecture, générez le code middleware.