système d'exploitation de voiture

1. Type de contrôleur de voiture

Il y a des centaines de contrôleurs dans une voiture, allant du moteur, de la boîte de vitesses, du moteur, de l'ESP, au grand écran de contrôle central, au système voiture-machine, à l'assistance de voie, etc.

Contrôle électronique automobile :

• En envoyant directement des instructions aux actionneurs (tels que les vannes électroniques, les commutateurs de relais, les moteurs exécutifs, etc.) pour contrôler les systèmes coopérants tels que le moteur, la boîte de vitesses et la batterie d'alimentation. Ce type de système a des exigences très élevées en matière de performances temps réel, et nécessite généralement un niveau de sécurité fonctionnelle.

Électronique du véhicule :

• Tels que l'instrumentation, le contrôle central, l'affichage tête haute (HUD), le rétroviseur multimédia en continu, etc. Ce type de système est souvent lié à l'expérience utilisateur, ne participe pas directement à la prise de décision de contrôle de la conduite du véhicule et a peu d'impact sur les performances et la sécurité de conduite du véhicule.

En raison de la différence d'exigences en temps réel entre les deux, le système d'exploitation a progressivement évolué en deux types, le système d'exploitation en temps réel , RTOS en abrégé, et le système d'exploitation à temps partagé du système d'exploitation à temps partagé.

Le système d'exploitation en temps réel signifie que lorsque des événements ou des données externes sont générés, ils peuvent les accepter et les traiter à une vitesse suffisamment rapide, et les résultats du traitement peuvent contrôler le processus de production ou répondre rapidement au système de traitement dans le délai spécifié, et contrôler Un système d'exploitation dans lequel toutes les tâches en temps réel s'exécutent à l'unisson. RTOS courants tels que : Ucos, Free Rtos, etc.

Le système d'exploitation à temps partagé est un système d'exploitation interactif multi-utilisateurs en ligne. Généralement, une méthode de rotation des tranches de temps est adoptée pour permettre à un ordinateur de desservir plusieurs terminaux. Il peut garantir un temps de réponse suffisamment rapide pour chaque utilisateur et fournir des capacités de session interactives.Le système d'exploitation pour PC que nous utilisons actuellement est basé sur cette méthode.

Prenons l'exemple du contrôleur d'airbag, puisqu'il s'agit d'une fonction critique liée à la sécurité, une très petite erreur de temps (trop tôt ou trop tard) peut avoir des conséquences catastrophiques et même faire des victimes, il faut donc utiliser un système d'exploitation en temps réel ; Pour le terminal, nous pouvons avoir besoin de passer un appel téléphonique tout en effectuant une navigation en temps réel, donc un système d'exploitation en temps partagé est utilisé.

Deux, Hyperviseur

L'émergence d'Hypervisor (technologie de virtualisation matérielle, fournissant une plate-forme virtuelle pour prendre en charge plusieurs systèmes d'exploitation) a entraîné la "fusion" des systèmes d'exploitation en temps réel et des systèmes d'exploitation à temps partagé)

D'une manière générale, Hypervisor est une méthode pour abstraire le système d'exploitation et le matériel, de sorte que le matériel de la machine hôte puisse exécuter une ou plusieurs machines virtuelles en tant que machines invitées en même temps, afin que ces machines virtuelles puissent partager efficacement les ressources matérielles de l'hôte. . .

L'émergence de l'hyperviseur rend possible le concept de "multi-système". Tant que les ressources sont suffisantes, on peut installer une variété de types différents, différents types et différents fournisseurs de systèmes d'exploitation sur le contrôleur pour répondre aux besoins de la couche supérieure fonctionne. Par exemple, nous pouvons installer un système d'infodivertissement ASIL QM dans le contrôleur de domaine du cockpit intelligent ou ajouter un système d'exploitation en temps réel ADAS qui répond à ASIL B/C.

3. QNX, Linux, Android

À l'heure actuelle, le système d'exploitation sous-jacent des automobiles est relativement stable.Les principaux acteurs sont QNX (Blackberry), Linux (Open Source Foundation) et Andorid (Google). Pour les contrôleurs tels que le domaine du cockpit, qui ont des exigences moindres en matière de sécurité fonctionnelle et de sécurité de l'information, le développement national est principalement basé sur Android/AliOS, et le développement étranger est principalement basé sur Linux ; tandis que les contrôleurs de conduite automatique avec un temps réel et une sécurité élevés sont toujours principalement basé sur le développement Linux/AliOS QNX.

QNX est un système d'exploitation en temps réel sécurisé à micro-noyau, intégré, non open source. En raison de son petit noyau, de sa vitesse de fonctionnement extrêmement rapide, de son architecture de micro-noyau unique, de sa haute sécurité et de sa stabilité, il s'agit du premier système d'exploitation en temps réel au monde à avoir passé la certification de sécurité ISO26262 ASIL-D et est souvent utilisé dans les instruments numériques à haute sécurité. et les exigences de stabilité au milieu. Avec sa sécurité, sa stabilité et d'autres avantages, il occupe une part de marché élevée et plus de 175 millions de véhicules utilisent le système QNX.

Linux est un système d'exploitation open source plus puissant. Linux a les caractéristiques d'un noyau compact et efficace, qui peut faire jouer pleinement les performances du matériel. Par rapport à QNX, son plus grand avantage est qu'il est open source et offre une grande flexibilité dans le développement personnalisé. Nous mentionnons généralement le développement de nouveaux systèmes d'exploitation basés sur Linux se réfère à l'intégration plus poussée du middleware, de l'environnement de bureau et de certains logiciels d'application basés sur Linux Kernel. Linux est plus puissant et possède des composants plus complexes que QNX, donc Linux est souvent utilisé dans les systèmes d'infodivertissement qui prennent en charge plus d'applications et d'interfaces.

AGL (Automotive Grade Linux) est un projet open source collaboratif qui rassemble des constructeurs automobiles, des fournisseurs et des entreprises technologiques pour accélérer le développement et l'adoption d'une pile logicielle entièrement ouverte pour la voiture connectée. Avec Linux en son cœur, AGL développe à partir de zéro une plate-forme ouverte qui peut être utilisée comme une norme industrielle de facto pour permettre le développement rapide de nouvelles fonctionnalités et technologies. Au début, AGL était principalement composé de fabricants japonais tels que Toyota, Honda et Nissan.Avec l'ajout de Volkswagen et Hyundai en 2019, l'échelle d'AGL s'est progressivement élargie. En mars 2020, des entreprises nationales telles que China Mobile, SAIC Motor, Desay SV et Thundersoft ont rejoint AGL, avec un total de plus de 150 membres.

Android est un système d'exploitation développé par Google et l'Open Handset Alliance basé sur Linux. Il est connu comme l'un des produits les plus performants développés sur la base de Linux. Il possède l'écosystème d'applications le plus riche et est principalement utilisé dans les appareils mobiles. L'APP sur le téléphone Android peut être appliquée à la voiture sans modifications majeures, ce qui est propice aux fabricants Internet nationaux entrant dans le domaine automobile et établissant rapidement un écosystème de logiciels automobiles. En particulier, les grands géants de l'Internet, les marques autonomes et les nouvelles forces de construction automobile ont réalisé des transformations personnalisées basées sur Android et lancé leurs propres systèmes d'exploitation automobiles, tels que Ali AliOS, Baidu Xiaodu Vehicle OS, BYD DiLink, Weilai NIO OS , Système d'exploitation Xiaopeng Xmart, etc.

4. Linux de qualité automobile (AGL)

1. Introduction

Automotive Grade Linux est une plate-forme système embarquée open source.

Automotive Grade Linux (AGL en abrégé) est un projet open source dirigé par la Linux Foundation. Il s'agit d'un projet développé par un groupe de développement formé de constructeurs automobiles, de fournisseurs et d'entreprises technologiques.

AGL est un système d'exploitation développé pour l'environnement du véhicule, que nous appelons généralement In-Vehicle Infotainment (IVI en abrégé). Plus loin : Android et la voiture

Les familiers Android Auto et Apple CarPlay appartiennent également au système IVI.

2. État actuel du marché IVI

Le tableau suivant résume le système IVI et les informations système sous-jacentes de plusieurs grands constructeurs automobiles :

Jusqu'à présent, le QNX de BlackBerry a un avantage absolu en termes de part de marché. Voici une comparaison de plusieurs systèmes traditionnels :

3. Structure du système

Démarrage rapide , Démarrage rapide

Le processus de construction du système AGL est le suivant :

• Système hôte prêt pour le développement
• Télécharger l'environnement de compilation AGL
• Initialiser l'environnement de compilation
• Compiler l'image système

Ensuite, nous allons construire selon ce processus.

(1) Le système hôte à développer

L'environnement de développement d'AGL doit utiliser le système de compilation Yocto Project , il est donc nécessaire de préparer l'environnement de développement sur cette base.

Actuellement, les versions Linux supportées par le Yocto Project sont les suivantes :

Ubuntu 14.10
Ubuntu 15.04
Ubuntu 15.10
Ubuntu 16.04 （LTS）
Fedora release 22
Fedora release 23
Fedora release 24
CentOS release 7.x
Debian GNU/Linux 8.x （Jessie）
Debian GNU/Linux 9.x （Stretch）
openSUSE 13.2
openSUSE 42.1

Considérant qu'Ubuntu Linux est utilisé par la plupart des gens, l'auteur vous recommande d'utiliser ce système pour la préparation.

Après avoir installé le système Ubuntu, vous devez installer les packages de développement suivants pour compiler le système AGL :

sudo apt-get install gawk wget git-core diffstat unzip texinfo gcc-multilib \
     build-essential chrpath socat cpio python python3 python3-pip python3-pexpect \
     xz-utils debianutils iputils-ping libsdl1.2-dev xterm

(2) Téléchargez l'environnement de compilation AGL

Le projet AGL contient de nombreux sous-projets, il est donc recommandé de créer un nouveau dossier pour stocker les fichiers associés.

Ici, nous prenons le dossier workspace_agl comme exemple pour construire l'environnement de compilation.

export AGL_TOP=$HOME/workspace_agl
mkdir -p $AGL_TOP

AGL utilise l'outil de dépôt pour gérer le code source, vous devez donc d'abord télécharger cet outil :

mkdir -p ~/bin
export PATH=~/bin:$PATH
curl https://storage.googleapis.com/git-repo-downloads/repo > ~/bin/repo
chmod a+x ~/bin/repo

Après avoir obtenu l'outil, vous pouvez télécharger différentes versions de l'environnement en fonction de vos besoins.

Si vous souhaitez obtenir le code source stable, vous pouvez utiliser la commande suivante :

cd $AGL_TOP
repo init -b flounder -u https://gerrit.automotivelinux.org/gerrit/AGL/AGL-repo
repo sync

Si vous souhaitez obtenir la dernière version, vous pouvez utiliser la commande suivante :

cd $AGL_TOP
repo init -u https://gerrit.automotivelinux.org/gerrit/AGL/AGL-repo
repo sync

(3) Initialiser l'environnement de compilation

Une fois le téléchargement terminé, vous devez initialiser l'environnement de compilation via un script, qui se trouve dans le chemin suivant :

$AGL_TOP/meta-agl/scripts/aglsetup.sh

Grâce à ce script, vous pouvez définir des paramètres de compilation, tels que : le matériel cible, le répertoire de la sortie compilée, etc.

Vous pouvez afficher l'aide avec la commande suivante :

source meta-agl/scripts/aglsetup.sh -h

Avant d'exécuter le script aglsetup.sh, vous devez déterminer les fonctionnalités du système AGL que vous souhaitez compiler.

La sélection d'entités peut être déterminée en spécifiant des couches. Actuellement, trois couches principales sont utilisées :

meta-agl：包含AGL发行版的最小集合。
meta-agl-demo：包含了参考UI实现以及演示平台和应用。
meta-agl-devel：包含了开发中的模块。这个也会包含OEM需要的但不在AGL中的软件包。

Ici, nous n'avons qu'à compiler le système de démonstration qui peut s'exécuter dans le simulateur, alors exécutez la commande suivante :

source meta-agl/scripts/aglsetup.sh -f -m qemux86-64 agl-demo agl-devel

Après avoir exécuté cette commande, le script générera le fichier de configuration nécessaire à la compilation.

(4) Compiler l'image système

Saisissez ensuite la commande suivante :

bitbake agl-demo-platform

Cette étape prend du temps, peut-être plusieurs heures, car elle implique le téléchargement et la compilation. La durée exacte dépend de votre environnement réseau et de la configuration matérielle de votre machine de développement.

Une fois la compilation terminée, l'image système sera automatiquement générée.

(5) Démarrer le produit compilé

L'image compilée se trouve build/tmp/deploy/images/dans le répertoire. Il existera dans différents sous-dossiers en fonction des paramètres de compilation. Le nom de fichier de l'image est suffixé par vmdk.

Par exemple, selon la configuration ci-dessus, l'image compilée cette fois est :

build/tmp/deploy/images/qemux86-64/agl-demo-platform-qemux86-64-20190529011851.rootfs.wic.vmdk

Ce fichier peut être démarré via QEMU ou via VirtualBox.

Après avoir copié le fichier vmdk ci-dessus sur le MacBook Pro, l'auteur a créé une nouvelle machine virtuelle via VirtualBox, et la configuration est la suivante :

(6) Architecture du système

La description fonctionnelle complète du système AGL peut être trouvée ici : "Automotive Grade Linux Requirements Specification" .

Ce document décrit l'architecture globale du système d'AGL et explique chaque module.

Le schéma de l'architecture du système est le suivant :

Sur cette image, nous pouvons voir que l'ensemble du système AGL peut être divisé en quatre couches. De haut en bas c'est :

• Couche d'application et d'interface : contient divers types de programmes d'application et l'interface d'exploitation avec laquelle les utilisateurs entrent en contact.
• Application Framework Layer : Fournit des interfaces pour gérer les applications en cours d'exécution. Cette couche est divisée en trois parties : application locale, cadre d'application AGL et application Web.
• Couche de service : contient des services auxquels toutes les applications de l'espace utilisateur peuvent accéder. Ces services sont divisés en deux catégories : les services de plate-forme et les services de voiture.
• Couche du système d'exploitation : contient le noyau du système et les pilotes des périphériques.

(7) Parcourir le code source

En fait, ce qui est obtenu grâce à repol'outil n'est pas le code source du système, mais uniquement les métadonnées du projet. Le vrai code source ne sera extrait que pendant le processus de compilation. Après extraction, le code source se trouve build/tmp/work/dans le répertoire.

En parcourant le code source, vous constaterez que le projet AGL est utilisé CMakecomme outil de configuration pour la compilation, vous pouvez donc comprendre le produit cible du projet en affichant le CMakeLists.txt de chaque projet.

En raison de l'espace limité, la section suivante présente le cadre d'application de base et le cadre d'interface homme-machine dans le système.

(8) Cadre d'application

Application Framework (Application Framework) est responsable de la gestion de toutes les applications. Il existe deux grands types de gestion

• Statique : comprend l'installation et la désinstallation de l'application.
• Dynamique : gestion du temps d'exécution des applications, telles que : démarrage et sortie d'application, basculement entre les applications, etc.

Le noyau du cadre d'application est afm-system-daemonconstitué de afm-user-daemondeux modules. Ce sont deux processus distincts qui D-Buscommuniquent via . Comme indiqué ci-dessous:

D-Bus est un mécanisme avancé de communication inter-processus fourni par le projet freedesktop.org et publié sous licence GPL. L'objectif principal de D-Bus est de fournir une communication pour les processus dans l'environnement de bureau Linux, et en même temps, il peut transmettre l'environnement de bureau Linux et les événements du noyau Linux au processus sous forme de messages. La principale probabilité de D-Bus est le bus. Le processus enregistré peut recevoir ou transmettre des messages via le bus. Le processus peut également s'enregistrer et attendre la réponse à l'événement du noyau, comme attendre que l'état du réseau change ou que l'ordinateur émette une commande d'arrêt. Actuellement, D-Bus a été adopté par la plupart des distributions Linux, et les développeurs peuvent utiliser D-Bus pour implémenter diverses tâches complexes de communication inter-processus.

ref : Connaissance de base de DBUS (très complète)

dans,

• afm-system-daemon Responsable de l'installation et de la désinstallation de l'application
• afm-user-daemon Responsable de la gestion du cycle de vie de l'application, y compris : démarrage, sortie, suspension et reprise, etc.

L'adresse du projet du framework d'application est ici : src/app-framework-main .

Le code source peut être obtenu directement par la commande suivante :

git clone "https://gerrit.automotivelinux.org/gerrit/src/app-framework-main"

AGL utilise systemd pour gérer le démarrage des processus système.

afm-system-daemonLes configurations de démarrage de et afm-user-daemonsont les suivantes :

[Unit]
Description=Application Framework Master, system side
Requires=afm-system-setup.service

[Service]
#User=afm
#Group=afm
SyslogIdentifier=afm-system-daemon
ExecStart=/usr/bin/afb-daemon --name=afm-system-daemon --no-httpd --no-ldpaths --binding=@afm_libexecdir@/afm-binding.so --ws-server=sd:afm-main
Restart=on-failure
RestartSec=5
CapabilityBoundingSet=CAP_DAC_OVERRIDE CAP_MAC_OVERRIDE

[Install]
WantedBy=multi-user.target

[Unit]
Description=Application Framework Master, User side

[Service]
Type=dbus                                
BusName=org.AGL.afm.user          
ExecStart=/usr/bin/afm-user-daemon --user-dbus=unix:path=%t/bus unix:@afm_platform_rundir@/apis/ws/afm-main
Environment=AFM_APP_INSTALL_DIR=%%r
EnvironmentFile=-@afm_confdir@/unit.env.d/*
Restart=on-failure
RestartSec=5


[Install]
WantedBy=default.target

Comme on peut le voir sur la configuration ci-dessus :

• afm-system-daemonLancé par /usr/bin/afb-daemonl'exécutable.
• afm-user-daemonDémarré par /usr/bin/afm-user-daemon un exécutable.

afb-daemon est l'abréviation de Application Framework Binder Daemon.

Le processus système AGL expose les interfaces via D-Bus . Une description des interfaces exposées par ces deux services peut être trouvée ici : Les démons afm : L'interface D-Bus.

Les interfaces exposées par afm-system-daemon incluent les éléments suivants

install
uninstall

Les interfaces exposées par afm-user-daemon incluent les éléments suivants

runnables
detail
start
once
terminate
pause
resume
runners
state
install
uninstall

Parmi eux, les interfaces d'installation et de désinstallation de afm-user-daemon demanderont éventuellement afm-system-daemon.

（9）afm-user-daemon

La fonction principale de afm-user-daemon se trouve dans le fichier afm-user-daemon.c.

Il s'agit d'un processus démon. Après le démarrage du processus démon, il attend généralement que le message soit traité dans la boucle.

/* start servicing */
if (jbus_start_serving(user_bus) < 0) {
    
    
  ERROR("can't start server");
  return 1;
}

/* run until error */
for(;;)
  sd_event_run(evloop, (uint64_t)-1);
return 0;

La liaison du nom de l'interface externe et de l'implémentation interne est effectuée dans le fichier afm-binding.c :

static const afb_verb_t verbs[] =
{
    
    
	{
    
    .verb=_runnables_, .callback=runnables, .auth=&auth_detail,    .info="Get list of runnable applications",          .session=AFB_SESSION_CHECK },
	{
    
    .verb=_detail_   , .callback=detail,    .auth=&auth_detail,    .info="Get the details for one application",        .session=AFB_SESSION_CHECK },
	{
    
    .verb=_start_    , .callback=start,     .auth=&auth_start,     .info="Start an application",                       .session=AFB_SESSION_CHECK },
	{
    
    .verb=_once_     , .callback=once,      .auth=&auth_start,     .info="Start once an application",                  .session=AFB_SESSION_CHECK },
	{
    
    .verb=_terminate_, .callback=terminate, .auth=&auth_kill,      .info="Terminate a running application",            .session=AFB_SESSION_CHECK },
	{
    
    .verb=_pause_    , .callback=pause,     .auth=&auth_kill,      .info="Pause a running application",                .session=AFB_SESSION_CHECK },
	{
    
    .verb=_resume_   , .callback=resume,    .auth=&auth_kill,      .info="Resume a paused application",                .session=AFB_SESSION_CHECK },
	{
    
    .verb=_runners_  , .callback=runners,   .auth=&auth_state,     .info="Get the list of running applications",       .session=AFB_SESSION_CHECK },
	{
    
    .verb=_state_    , .callback=state,     .auth=&auth_state,     .info="Get the state of a running application",     .session=AFB_SESSION_CHECK },
	{
    
    .verb=_install_  , .callback=install,   .auth=&auth_install,   .info="Install an application using a widget file", .session=AFB_SESSION_CHECK },
	{
    
    .verb=_uninstall_, .callback=uninstall, .auth=&auth_uninstall, .info="Uninstall an application",                   .session=AFB_SESSION_CHECK },
	{
    
    .verb=NULL }
};

Il s'agit d'un tableau, chaque élément correspond à une liaison d'interface. .callback spécifie la fonction de rappel implémentée par la logique.

La gestion du cycle de vie de l'application dans afm-user-daemon est implémentée dans les fonctions suivantes :

extern int afm_urun_start(struct json_object *appli, int uid);
extern int afm_urun_once(struct json_object *appli, int uid);
extern int afm_urun_terminate(int runid, int uid);
extern int afm_urun_pause(int runid, int uid);
extern int afm_urun_resume(int runid, int uid);
extern struct json_object *afm_urun_list(struct afm_udb *db, int all, int uid);
extern struct json_object *afm_urun_state(struct afm_udb *db, int runid, int uid);
extern int afm_urun_search_runid(struct afm_udb *db, const char *id, int uid);

afm_run_once

int afm_urun_once(struct json_object *appli, int uid)
{
    
    
	const char *udpath, *state, *uscope, *uname;
	int rc, isuser;

	/* retrieve basis */
	rc = get_basis(appli, &isuser, &udpath, uid);
	if (rc < 0)
		goto error;

	/* start the unit */
	rc = systemd_unit_start_dpath(isuser, udpath);
	if (rc < 0) {
    
    
		j_read_string_at(appli, "unit-scope", &uscope);
		j_read_string_at(appli, "unit-name", &uname);
		ERROR("can't start %s unit %s for uid %d", uscope, uname, uid);
		goto error;
	}

	state = wait_state_stable(isuser, udpath);
	if (state == NULL) {
    
    
		j_read_string_at(appli, "unit-scope", &uscope);
		j_read_string_at(appli, "unit-name", &uname);
		ERROR("can't wait %s unit %s for uid %d: %m", uscope, uname, uid);
		goto error;
	}
	if (state != SysD_State_Active) {
    
    
		j_read_string_at(appli, "unit-scope", &uscope);
		j_read_string_at(appli, "unit-name", &uname);
		ERROR("start error %s unit %s for uid %d: %s", uscope, uname, uid, state);
		goto error;
	}

	rc = systemd_unit_pid_of_dpath(isuser, udpath);
	if (rc <= 0) {
    
    
		j_read_string_at(appli, "unit-scope", &uscope);
		j_read_string_at(appli, "unit-name", &uname);
		ERROR("can't getpid of %s unit %s for uid %d: %m", uscope, uname, uid);
		goto error;
	}

	return rc;

error:
	return -1;
}

Si vous parcourez ces codes sources, vous constaterez qu'il existe encore des logiques qui ne sont pas totalement implémentées :

int afm_urun_pause(int runid, int uid)
{
    
    
	return not_yet_implemented("pause");
}

int afm_urun_resume(int runid, int uid)
{
    
    
	return not_yet_implemented("resume");
}

(10)afb-démon

Le code source de l'exécutable afb-daemon se trouve dans un autre projet : src/app-framework-binder

Vous pouvez obtenir son code source avec la commande suivante :

git clone "https://gerrit.automotivelinux.org/gerrit/src/app-framework-binder"

Le classeur fournit les moyens de connecter l'application aux services requis. Avec binder, vous pouvez servir en toute sécurité des applications écrites dans n'importe quelle langue et exécutées presque n'importe où.

Le classeur ici n'est pas le même que le classeur dans Android.

La relation entre afb-daemon et l'application est illustrée dans la figure ci-dessous :

afb-daemon fournit à la fois une interface http et une interface WebSocket.

La fonction principale de afb-daemon se trouve dans le fichier main-afb-daemon.c. La logique principale dans sa fonction principale fait quatre choses :

解析传入的参数。
根据name参数设置进程名称。回顾一下上文，启动afm-system-daemon的时候就是通过systemd的配置文件指定了name参数：--name=afm-system-daemon。
设置为守护进程。
开始服务。

Étant donné que le processus démon peut être demandé simultanément par plusieurs clients en même temps, afb-daemon fonctionne de manière multithread. Plus précisément, il est implémenté via l'interface suivante :

int jobs_start(int allowed_count, int start_count,
int waiter_count, void (*start)(int signum, void* arg), void *arg)

Plusieurs paramètres sont ici expliqués comme suit :

allowed_count 最大支持的线程数量
start_count 初始启动的线程数量
waiter_count 最多等待的请求
start 处理请求的函数指针

Les valeurs définies pour ces paramètres dans la fonction principale sont les suivantes :

jobs_start(3, 0, 50, start, NULL);

（11）afm-util

Le framework d'application fournit un outil en ligne de commande pour faciliter le développement et les tests, le nom de cet outil est appelé afm-util.

Les fonctions fournies incluent les éléments suivants :

list
runnables      list the runnable widgets installed

add wgt
install wgt    install the wgt file

remove id
uninstall id   remove the installed widget of id

info id
detail id      print detail about the installed widget of id

ps
runners        list the running instance

run id
start id       start an instance of the widget of id

kill rid
terminate rid  terminate the running instance rid

status rid
state rid      get status of the running instance rid

(12) Cadre d'interface homme-machine

Le framework Interface Homme-Machine (IHM) comprend principalement les modules suivants :

WindowManager
HomeScreen
SoundManager
InputManager

Gestionnaire de fenêtres

• WindowManager Comme son nom l'indique, ce module se charge de la gestion des fenêtres du système. Le code source peut être obtenu par la commande suivante :

git clone https://gerrit.automotivelinux.org/gerrit/apps/agl-service-windowmanager

Le matériel que WindowManager doit gérer comprend : le périphérique d'affichage, le GPU, le périphérique d'entrée et la mémoire vidéo. Ses principales responsabilités comprennent :

绘制窗口
管理好窗口的层级
处理可视化效果动画
显示帧率管理
有效利用各种硬件，并减少硬件依赖
多窗口，多屏幕管理
兼容性管理

Ce qui suit n'est qu'une brève introduction à ce module.
L'architecture globale de WindowManager est présentée dans la figure ci-dessous :

Le module WindowManager se compose de quatre parties :

afb-binder
服务绑定库
用于策略管理的共享库
配置文件

Les applications peuvent utiliser libwindowmanager.so pour utiliser l'interface WindowManager. Les interfaces incluent les éléments suivants :

int requestSurface(const char* role);
int requestSurfaceXDG(const char* role, unsigned ivi_id);
int activateWindow(const char* role, const char* area);
int activateWindow(const char* role);
int deactivateWindow(const char* role);
int endDraw(const char* role);
struct Screen getScreenInfo();
int getAreaInfo(const char* role, Rect *out_rect);
void setEventHandler(const WMHandler& wmh);

L'implémentation du module de bureau HomeScreen
est contenue dans les projets suivants :

homescreen：HomeScreenGUI，这是一个Qt的应用程序
launcher：LauncherGUI，这是一个Qt的应用程序
gl-service-homescreen：HomeScreenBinder的绑定库
libhomescreen：提供来给应用程序与HomeScreenBinder通讯的库
libqthomescreen：提供给Qt应用程序与HomeScreenBinder通讯的库，基于libhomescreen

libhomescreen fournit un ensemble d'interfaces pour gérer le bureau : pour la description de ces interfaces, veuillez vous référer au fichier libhomescreen.cpp.

int init(const int port, const std::string& token);

	int tapShortcut(const char* application_id);
	int onScreenMessage(const char* display_message);
	int onScreenReply(const char* reply_message);

	void set_event_handler(enum EventType et, handler_func f);

	void registerCallback(
		void (*event_cb)(const std::string& event, struct json_object* event_contents),
		void (*reply_cb)(struct json_object* reply_contents),
		void (*hangup_cb)(void) = nullptr);

	int call(const std::string& verb, struct json_object* arg);
	int call(const char* verb, struct json_object* arg);
	int subscribe(const std::string& event_name);
	int unsubscribe(const std::string& event_name);

	int showWindow(const char* application_id, json_object* json);
	int hideWindow(const char* application_id);
	int replyShowWindow(const char* application_id, json_object* json);
	int showNotification(json_object* json);
	int showInformation(json_object* json);
	int getRunnables(void);

Par exemple, lors d'un clic sur une application, l'interface showWindow sera appelée pour afficher l'application concernée :

void HomescreenHandler::tapShortcut(QString application_id)
{
    
    
    HMI_DEBUG("Launcher","tapShortcut %s", application_id.toStdString().c_str());
    struct json_object* j_json = json_object_new_object();
    struct json_object* value;
    value = json_object_new_string("normal.full");
    json_object_object_add(j_json, "area", value);

    mp_hs->showWindow(application_id.toStdString().c_str(), j_json);
}

(13) Installez la boîte virtuelle dans un non-WSL pour démarrer l'AGL existant

La première étape consiste à installer vm sous windows : vm 6.0.24 windows et les packs d'extension ( tutoriel d'installation )

Étape 2 : Reportez-vous à 2. Virtual Box (émulation) pour installer AGL dans la VM

question:

Call to WHvSetupPartition failed: ERROR_SUCCESS (Last=0xc000000d/87) (VERR_NEM_VM_CREATE_FAILED).

résoudre:

Il existe un conflit entre WSL et les machines virtuelles virtuelles, vm. Activez donc le commutateur WSL comme suit :

bcdedit /set hypervisorlaunchtype off

Redémarrer le PC

Désactiver la prise en charge des machines virtuelles : référence

Ouvrir:

bcdedit /set hypervisorlaunchtype auto

Redémarrer le PC

Mots：

不要执行AGL中操作说明的下面这行代码：否则只显示终端了，不显示GUI了
VBoxManage setextradata agl-demo VBoxInternal2/EfiGraphicsResolution 1920x1080

================================================= ================================================

1) Installer la boîte virtuelle en non-WSL2 : 6.0.24

• Notez que wsl ne prend pas en charge virtualbox, veuillez vous référer à ce qui suit

方法1：（不建议）
 sudo dpkg -i virtualbox-6.0_6.0.24-139119_Ubuntu_eoan_amd64.deb


方法2：
echo "deb [arch=amd64] http://download.virtualbox.org/virtualbox/debian $(lsb_release -cs) contrib" | \
     sudo tee -a /etc/apt/sources.list.d/virtualbox.list
 sudo apt update
 apt-cache search virtualbox
 apt-cache search virtualbox-ext-pack
sudo apt install virtualbox
sudo apt install  virtualbox-ext-pack

ref : Comment installer VirtualBox sur Ubuntu 20.04 , Ubuntu : Solution au problème NO_PUBKEY (clé publique introuvable)

Problèmes avec la méthode 2 :

wangji@script-wang:/mnt/d/ubunt_tmp$ sudo apt update
Get:3 http://download.virtualbox.org/virtualbox/debian focal InRelease [4431 B]
Err:3 http://download.virtualbox.org/virtualbox/debian focal InRelease
  The following signatures couldn't be verified because the public key is not available: NO_PUBKEY A2F683C52980AECF
Hit:4 https://download.docker.com/linux/ubuntu focal InRelease
Hit:5 https://mirrors.tuna.tsinghua.edu.cn/ubuntu focal InRelease
Hit:6 https://mirrors.tuna.tsinghua.edu.cn/ubuntu focal-updates InRelease
Hit:7 https://mirrors.tuna.tsinghua.edu.cn/ubuntu focal-backports InRelease
Hit:8 https://mirrors.tuna.tsinghua.edu.cn/ubuntu focal-security InRelease
Hit:1 https://scala.jfrog.io/artifactory/debian all InRelease
Ign:2 https://scala.jfrog.io/artifactory/debian  InRelease
Hit:9 https://scala.jfrog.io/artifactory/debian  Release
Reading package lists... Done
W: GPG error: http://download.virtualbox.org/virtualbox/debian focal InRelease: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY A2F683C52980AECF
E: The repository 'http://download.virtualbox.org/virtualbox/debian focal InRelease' is not signed.
N: Updating from such a repository can't be done securely, and is therefore disabled by default.
N: See apt-secure(8) manpage for repository creation and user configuration details.

Solution : Ajoutez ce O_PUBKEY A2F683C52980AECF

1）gpg --keyserver keyserver.ubuntu.com --recv A2F683C52980AECF
    #  后面的字符串是NO_PUBKEY后的提供字符

2）gpg --export --armor A2F683C52980AECF| sudo apt-key add -
    #  注意命令最后面还有一个“-”，千万不要忘记了它！

2) Utilisez virtualbox, suivez le tutoriel 2. Virtual Box (Emulation) pour démarrer le fichier vmdk

启动virtualbox：

Problèmes avec la méthode 2 :

wangji@script-wang:/mnt/d/ubunt_tmp$ sudo virtualbox
WARNING: The vboxdrv kernel module is not loaded. Either there is no module
         available for the current kernel (5.10.102.1-microsoft-standard-WSL2) or it failed to
         load. Please recompile the kernel module and install it by

           sudo /sbin/vboxconfig

         You will not be able to start VMs until this problem is fixed.





Qt WARNING: could not connect to display 172.19.128.1:0
Qt FATAL: This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.

Available platform plugins are: eglfs, linuxfb, minimal, minimalegl, offscreen, vnc, xcb.

Résolu :

 export QT_DEBUG_PLUGINS=1 
 wangji@script-wang:/mnt/d/ubunt_tmp$ virtualbox

Problèmes avec la méthode 2 :

Unpacking virtualbox-dkms (6.1.38-dfsg-3~ubuntu1.20.04.1) over (6.1.38-dfsg-3~ubuntu1.20.04.1) ...
Setting up virtualbox-dkms (6.1.38-dfsg-3~ubuntu1.20.04.1) ...
Loading new virtualbox-6.1.38 DKMS files...
It is likely that 5.10.102.1-microsoft-standard-WSL2 belongs to a chroot's host
Building for 5.4.0-1013-iot and 5.4.0-146-generic
Module build for kernel 5.4.0-1013-iot was skipped since the
kernel headers for this kernel does not seem to be installed.
Building initial module for 5.4.0-146-generic
Done.

résoudre:

wangji@script-wang:~$ apt-cache search  5.4.0-1013-iot
wangji@script-wang:~$ supd apt-get install -y linux-headers-5.4.0-1013-iot

Problèmes avec la méthode 2 :

wangji@script-wang:~$ sudo dpkg --configure -a
Setting up grub-pc (2.04-1ubuntu26.16) ...
dpkg: error processing package grub-pc (--configure):
 installed grub-pc package post-installation script subprocess returned error exit status 10
dpkg: dependency problems prevent configuration of grub-gfxpayload-lists:
 grub-gfxpayload-lists depends on grub-pc (>= 1.99~20101210-1ubuntu2); however:
  Package grub-pc is not configured yet.

résoudre:

• dpkg : erreur de traitement du package *** (–configure) solution d'erreur

wangji@script-wang:~$ sudo dpkg --configure -a
Setting up grub-pc (2.04-1ubuntu26.16) ...
dpkg: error processing package grub-pc (--configure):
 installed grub-pc package post-installation script subprocess returned error exit status 10
dpkg: dependency problems prevent configuration of grub-gfxpayload-lists:
 grub-gfxpayload-lists depends on grub-pc (>= 1.99~20101210-1ubuntu2); however:
  Package grub-pc is not configured yet.

Problèmes avec la méthode 2 :

wangji@script-wang:~$ virtualbox
WARNING: The character device /dev/vboxdrv does not exist.
         Please install the virtualbox-dkms package and the appropriate
         headers, most likely linux-headers-standard.

résoudre:

wangji@script-wang:~$ sudo apt-get install --reinstall virtualbox-dkms -y

4. Développement d'applications AGL

Le système AGL prend en charge à la fois les applications Web et les applications natives. Le cadre du système gérera la gestion des différents types d'applications.

Évidemment, l'image système correspondante doit être obtenue avant le développement de l'application AGL. Si vous ne disposez pas de votre propre environnement de compilation, vous pouvez télécharger l'image compilée à partir du site officiel .

Il existe deux modes de développement d'applications AGL :

• Utilisez le kit de développement logiciel (SDK en abrégé)
• Utiliser le système de développement croisé (XDS en abrégé)

XDS est la méthode officiellement recommandée. XDS prend en charge la création, le déploiement et l'exécution de projets personnels sur le système cible via le tableau de bord XDS ou la ligne de commande XDS.

Voir ici pour plus d'informations sur la façon de développer des applications AGL : Guides du développeur.

5. Hyperviseur QNX

Comme mentionné précédemment, le système QNX de BlackBerry détient la part la plus élevée sur le marché IVI actuel. Ceci est principalement dû à ses caractéristiques de sécurité et de stabilité.

Cependant, QNX lui-même est un logiciel commercial payant et n'est pas open source, il est donc plus difficile de le personnaliser en profondeur.

Heureusement, le système QNX dispose d'une fonction Hypervisor, qui est similaire à la fonction de machine virtuelle sur un ordinateur : exécutez d'autres systèmes d'exploitation sur la base de QNX, tels que les systèmes Linux ou Android. Comme indiqué ci-dessous:

réf：

• 5 minutes, vous amènent à comprendre le système d'exploitation automobile , introduction au système Automotive Grade Linux