sistema operativo del coche

1. Tipo de controlador de coche

Hay cientos de controladores en un automóvil, que van desde el motor, la caja de cambios, el motor, el ESP, hasta la gran pantalla de control central, el sistema automóvil-máquina, la asistencia de carril, etc.

Control electrónico automotriz:

  • Mediante el envío directo de instrucciones a los actuadores (como válvulas electrónicas, interruptores de relé, motores ejecutivos, etc.) para controlar los sistemas cooperantes, como el motor, la caja de cambios y la batería de potencia. Este tipo de sistema tiene requisitos muy altos para el rendimiento en tiempo real y generalmente requiere un nivel de seguridad funcional.

Electrónica del vehículo:

  • Como instrumentación, control central, pantalla de visualización frontal (HUD), espejo retrovisor de transmisión de medios, etc. Este tipo de sistema a menudo está relacionado con la experiencia del usuario, no participa directamente en la toma de decisiones de control de la conducción del vehículo y tiene poco impacto en el rendimiento y la seguridad de la conducción del vehículo.

Debido a la diferencia en los requisitos de tiempo real entre los dos, el sistema operativo se ha convertido gradualmente en dos tipos, el sistema operativo en tiempo real , RTOS para abreviar, y el sistema operativo de tiempo compartido del sistema operativo de tiempo compartido.

El sistema operativo en tiempo real significa que cuando se generan eventos o datos externos, pueden aceptarlos y procesarlos a una velocidad lo suficientemente rápida, y los resultados del procesamiento pueden controlar el proceso de producción o responder rápidamente al sistema de procesamiento dentro del tiempo especificado y controlar Un sistema operativo en el que todas las tareas en tiempo real se ejecutan al unísono. RTOS comunes como: Ucos, Free Rtos, etc.

El sistema operativo de tiempo compartido es un sistema operativo interactivo multiusuario en línea. Generalmente, se adopta un método de rotación de segmentos de tiempo para permitir que una computadora sirva a múltiples terminales. Puede garantizar un tiempo de respuesta lo suficientemente rápido para cada usuario y proporcionar capacidades de sesión interactiva.El sistema operativo de PC que usamos ahora se basa en este método.

Tomemos como ejemplo el controlador de bolsas de aire, ya que esta es una función crítica relacionada con la seguridad, un error de tiempo muy pequeño (demasiado temprano o demasiado tarde) puede tener consecuencias catastróficas e incluso causar víctimas, por lo que se debe utilizar un sistema operativo en tiempo real; Para el terminal, es posible que necesitemos realizar una llamada telefónica mientras realizamos una navegación en tiempo real, por lo que se utiliza un sistema operativo de tiempo compartido.

dos, hipervisor

El surgimiento de Hypervisor (tecnología de virtualización de hardware, que proporciona una plataforma virtual para admitir múltiples sistemas operativos) ha provocado la "fusión" de los sistemas operativos en tiempo real y los sistemas operativos de tiempo compartido)
inserte la descripción de la imagen aquí

En términos generales, Hypervisor es un método para abstraer el sistema operativo y el hardware, de modo que el hardware de la máquina host pueda ejecutar una o más máquinas virtuales como máquinas invitadas al mismo tiempo, de modo que estas máquinas virtuales puedan compartir de manera eficiente los recursos de hardware host. . .

inserte la descripción de la imagen aquí

La aparición del hipervisor hace posible el concepto de "multisistema". Mientras los recursos sean suficientes, podemos instalar una variedad de diferentes tipos, diferentes tipos y diferentes proveedores de sistemas operativos en el controlador para satisfacer las necesidades de las funciones de la capa superior. Por ejemplo, podemos instalar un sistema de información y entretenimiento ASIL QM en el controlador de dominio de la cabina inteligente o agregar un sistema operativo en tiempo real ADAS que cumpla con ASIL B/C.

3. QNX, Linux, Android

En la actualidad, el sistema operativo subyacente de los automóviles es relativamente estable. Los principales actores son QNX (Blackberry), Linux (Open Source Foundation) y Andorid (Google). Para los controladores como el dominio de la cabina, que tienen requisitos más bajos para la seguridad funcional y la seguridad de la información, el desarrollo nacional se basa principalmente en Android/AliOS, y el desarrollo extranjero se basa principalmente en Linux; mientras que los controladores de conducción automática con alto tiempo real y seguridad son todavía basado principalmente en Linux/AliOS QNX orientado al desarrollo.
inserte la descripción de la imagen aquí

QNX es un sistema operativo en tiempo real seguro, integrado, de código no abierto y microkernel. Debido a su núcleo pequeño, velocidad de ejecución extremadamente rápida, arquitectura de micronúcleo única, alta seguridad y estabilidad, es el primer sistema operativo en tiempo real del mundo que ha pasado la certificación de seguridad ISO26262 ASIL-D y se usa a menudo en instrumentos digitales con alta seguridad. y requisitos de estabilidad medio. Con su seguridad, estabilidad y otras ventajas, ocupa una alta cuota de mercado y más de 175 millones de vehículos utilizan el sistema QNX.
inserte la descripción de la imagen aquí

Linux es un sistema operativo de código abierto y más potente. Linux tiene las características de un núcleo compacto y eficiente, que puede aprovechar al máximo el rendimiento del hardware. En comparación con QNX, su mayor ventaja es que es de código abierto y tiene una gran flexibilidad en el desarrollo personalizado. Usualmente mencionamos que el desarrollo de nuevos sistemas operativos basados ​​en Linux se refiere a una mayor integración de middleware, entorno de escritorio y algún software de aplicación basado en Linux Kernel. Linux es más poderoso y tiene componentes más complejos que QNX, por lo que Linux se usa a menudo en sistemas de infoentretenimiento que admiten más aplicaciones e interfaces.

AGL (Automotive Grade Linux) es un proyecto colaborativo de código abierto que reúne a fabricantes de automóviles, proveedores y empresas de tecnología para acelerar el desarrollo y la adopción de una pila de software completamente abierta para el automóvil conectado. Con Linux como núcleo, AGL está desarrollando desde cero una plataforma abierta que se puede utilizar como un estándar industrial de facto para permitir el rápido desarrollo de nuevas características y tecnologías. En los primeros días, AGL era principalmente fabricantes japoneses como Toyota, Honda y Nissan. Con la incorporación de Volkswagen y Hyundai en 2019, la escala de AGL ha crecido gradualmente. A partir de marzo de 2020, empresas nacionales como China Mobile, SAIC Motor, Desay SV y Thundersoft se han unido a AGL, con un total de más de 150 miembros.

Android es un sistema operativo desarrollado por Google y Open Handset Alliance basado en Linux, es conocido como uno de los productos más exitosos desarrollados en base a Linux, tiene el ecosistema de aplicaciones más rico y se utiliza principalmente en dispositivos móviles. La aplicación en el teléfono Android se puede aplicar al automóvil sin modificaciones importantes, lo que favorece que los fabricantes nacionales de Internet ingresen al campo automotriz y establezcan rápidamente un ecosistema de software para automóviles. En particular, los principales gigantes de Internet, las marcas propias y las nuevas fuerzas de fabricación de automóviles han llevado a cabo transformaciones personalizadas basadas en Android y han lanzado sus propios sistemas operativos para automóviles, como Ali AliOS, Baidu Xiaodu Vehicle OS, BYD DiLink, Weilai NIO OS. , sistema operativo Xiaopeng Xmart, etc.

4. Linux de grado automotriz (AGL)

1. Introducción

Automotive Grade Linux es una plataforma de sistema para vehículos de código abierto.

Automotive Grade Linux (AGL para abreviar) es un proyecto de código abierto dirigido por la Fundación Linux. Este es un proyecto desarrollado por un grupo de desarrollo formado por fabricantes de automóviles, proveedores y empresas de tecnología.

AGL es un sistema operativo desarrollado para el entorno del vehículo. Normalmente llamamos a este sistema In-Vehicle Infotainment (IVI para abreviar). Más: Android y el coche

Los conocidos Android Auto y Apple CarPlay también pertenecen al sistema IVI.

2. Situación actual del mercado IVI

La siguiente tabla resume el sistema IVI y la información del sistema subyacente de varios de los principales fabricantes de automóviles:
inserte la descripción de la imagen aquí
Hasta el momento, QNX de BlackBerry tiene una ventaja absoluta en la participación de mercado. La siguiente es una comparación de varios sistemas convencionales:
inserte la descripción de la imagen aquí

3. Construcción del sistema

inicio rápido , inicio rápido

El proceso de construcción del sistema AGL es el siguiente:

  • Sistema host listo para el desarrollo
  • Descargar el entorno de compilación AGL
  • Inicializar el entorno de compilación
  • Compilar la imagen del sistema

A continuación, construiremos de acuerdo con este proceso.

(1) El sistema host a desarrollar

El entorno de desarrollo de AGL necesita utilizar el sistema de compilación Yocto Project , por lo que es necesario preparar el entorno de desarrollo en base a este.

Actualmente, las versiones de Linux compatibles con el Proyecto Yocto incluyen las siguientes:

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

Teniendo en cuenta que Ubuntu Linux es utilizado por la mayoría de las personas, el autor recomienda que utilice este sistema para la preparación.

Después de instalar el sistema Ubuntu, debe instalar los siguientes paquetes de desarrollo para compilar el sistema 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) Descargue el entorno de compilación AGL

El proyecto AGL contiene muchos subproyectos, por lo que se recomienda que cree una nueva carpeta para almacenar archivos relacionados.

Aquí tomamos la carpeta workspace_agl como ejemplo para construir el entorno de compilación.

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

AGL usa la herramienta de repositorio para administrar el código fuente, por lo que primero debe descargar esta herramienta:

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

Después de obtener la herramienta, puede descargar diferentes versiones del entorno según sus necesidades.

Si desea obtener el código fuente estable, puede usar el siguiente comando:

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

Si desea obtener la última versión, puede usar el siguiente comando:

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

(3) Inicializar el entorno de compilación

Una vez completada la descarga, debe inicializar el entorno de compilación a través de un script, que se encuentra en la siguiente ruta:

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

A través de este script, puede establecer parámetros de compilación, como: hardware de destino, directorio de salida compilada, etc.

Puede ver la ayuda con el siguiente comando:

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

Antes de ejecutar el script aglsetup.sh, debe determinar qué funciones del sistema AGL desea compilar.

La selección de características se puede determinar mediante la especificación de capas.Actualmente, hay tres capas principales en uso:

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

Aquí solo necesitamos compilar el sistema de demostración que se puede ejecutar en el simulador, así que ejecute el siguiente comando:

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

Después de ejecutar este comando, el script generará el archivo de configuración necesario para la compilación.

(4) compilar la imagen del sistema

Luego ingrese el siguiente comando:

bitbake agl-demo-platform

Este paso requiere mucho tiempo, posiblemente varias horas, ya que implica descargar y compilar. El tiempo exacto depende de su entorno de red y la configuración de hardware de su máquina de desarrollo.

Una vez completada la compilación, la imagen del sistema se generará automáticamente.

(5) Inicie el producto compilado

La imagen compilada se encuentra build/tmp/deploy/images/en el directorio. Existirá en diferentes subcarpetas según la configuración de tiempo de compilación. El nombre de archivo de la imagen tiene el sufijo vmdk.

Por ejemplo, según la configuración anterior, la imagen compilada esta vez es:

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

Este archivo se puede iniciar mediante QEMU o mediante VirtualBox.

Después de copiar el archivo vmdk anterior en la MacBook Pro, el autor creó una nueva máquina virtual a través de VirtualBox y la configuración es la siguiente:
inserte la descripción de la imagen aquí
inserte la descripción de la imagen aquí

(6) Arquitectura del sistema

La descripción funcional completa del sistema AGL se puede encontrar aquí: "Especificación de requisitos de Linux de grado automotriz" .

Este documento describe la arquitectura general del sistema de AGL y explica cada módulo.

El diagrama de la arquitectura del sistema es el siguiente:
inserte la descripción de la imagen aquí

En esta imagen podemos ver que todo el sistema AGL se puede dividir en cuatro capas. De arriba a abajo esto es:

  • Capa de aplicación e interfaz: contiene varios tipos de programas de aplicación y la interfaz de operación con la que los usuarios entran en contacto.
  • Capa de marco de aplicación: proporciona interfaces para administrar aplicaciones en ejecución. Esta capa se divide en tres partes: aplicación local, marco de aplicación de AGL y aplicación web.
  • Capa de servicio: contiene servicios a los que pueden acceder todas las aplicaciones en el espacio del usuario.Estos servicios se dividen en dos categorías: servicios de plataforma y servicios de automóvil.
  • Capa del sistema operativo: contiene el núcleo del sistema y los dispositivos del controlador.

(7) Explorar el código fuente

De hecho, repolo que se obtiene a través de la herramienta no es el código fuente del sistema, sino únicamente los metadatos del proyecto. El código fuente real solo se extraerá durante el proceso de compilación. Después de extraer, el código fuente se encuentra build/tmp/work/en el directorio.

Al explorar el código fuente, encontrará que el proyecto AGL se usa CMakecomo una herramienta de configuración para la compilación, por lo que puede comprender el producto de destino del proyecto al ver el CMakeLists.txt de cada proyecto.

Debido al espacio limitado, la siguiente sección presenta el marco de la aplicación central y el marco de la interfaz hombre-máquina en el sistema.

(8) Marco de aplicación

Application Framework (Application Framework) es responsable de administrar todas las aplicaciones. Hay dos tipos principales de gestión.

  • Estático: incluye la instalación y desinstalación de la aplicación.
  • Dinámico: gestión del tiempo de ejecución de las aplicaciones, como: inicio y salida de aplicaciones, cambio entre aplicaciones, etc.

El núcleo del marco de la aplicación es afm-system-daemony afm-user-daemondos módulos. Estos son dos procesos separados que D-Busse comunican a través de . Como se muestra abajo:

D-Bus es un mecanismo avanzado de comunicación entre procesos proporcionado por el proyecto freedesktop.org y publicado bajo la licencia GPL. El objetivo principal de D-Bus es proporcionar comunicación para los procesos en el entorno de escritorio de Linux y, al mismo tiempo, puede pasar el entorno de escritorio de Linux y los eventos del kernel de Linux al proceso como mensajes. La principal probabilidad de D-Bus es el bus. El proceso registrado puede recibir o transmitir mensajes a través del bus. El proceso también puede registrarse y esperar la respuesta del evento del kernel, como esperar a que cambie el estado de la red o que la computadora emita un comando de apagado. Actualmente, D-Bus ha sido adoptado por la mayoría de las distribuciones de Linux, y los desarrolladores pueden usar D-Bus para implementar varias tareas complejas de comunicación entre procesos.

ref: Conocimientos básicos de DBUS (muy completo)

inserte la descripción de la imagen aquí

en,

  • afm-system-daemon Responsable de la instalación y desinstalación de aplicaciones.
  • afm-user-daemon Responsable de la gestión del ciclo de vida de la aplicación, incluyendo: inicio, salida, suspensión y reanudación, etc.

La dirección del proyecto del marco de la aplicación está aquí: src/app-framework-main .

El código fuente se puede obtener directamente con el siguiente comando:

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

AGL usa systemd para administrar el inicio de los procesos del sistema.

afm-system-daemonLas configuraciones de inicio de y afm-user-daemonson las siguientes:

[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

Como se puede ver en la configuración anterior:

  • afm-system-daemonIniciado por /usr/bin/afb-daemonel ejecutable.
  • afm-user-daemonIniciado por /usr/bin/afm-user-daemon un ejecutable.

afb-daemon es la abreviatura de Application Framework Binder Daemon.

El proceso del sistema AGL expone interfaces a través de D-Bus . Puede encontrar una descripción de las interfaces expuestas por estos dos servicios aquí: Los demonios afm: La interfaz D-Bus.

Las interfaces expuestas por afm-system-daemon incluyen las siguientes

install
uninstall

Las interfaces expuestas por afm-user-daemon incluyen lo siguiente

runnables
detail
start
once
terminate
pause
resume
runners
state
install
uninstall

Entre ellos, las interfaces de instalación y desinstalación de afm-user-daemon eventualmente solicitarán afm-system-daemon.

(9) afm-user-daemon

La función principal de afm-user-daemon se encuentra en el archivo afm-user-daemon.c.

Este es un proceso daemon Después de que se inicia el proceso daemon, normalmente espera a que el mensaje se procese en el ciclo.

/* 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 vinculación del nombre de la interfaz externa y la implementación interna se realiza en el archivo 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 }
};

Esta es una matriz, cada elemento corresponde a un enlace de interfaz. .callback especifica la función de devolución de llamada implementada por la lógica.

La gestión del ciclo de vida de la aplicación en afm-user-daemon se implementa en las siguientes funciones:

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 explora estos códigos fuente, encontrará que todavía hay algunas lógicas que no están completamente implementadas:

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-demonio

El código fuente del ejecutable afb-daemon se encuentra en otro proyecto: src/app-framework-binder

Puede obtener su código fuente con el siguiente comando:

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

El archivador proporciona los medios para conectar la aplicación a los servicios requeridos. Con Binder, puede servir de forma segura aplicaciones escritas en cualquier idioma y ejecutarse en casi cualquier lugar.

El archivador aquí no es el mismo que el archivador en Android.

La relación entre afb-daemon y la aplicación se muestra en la siguiente figura:
inserte la descripción de la imagen aquí

afb-daemon proporciona tanto la interfaz http como la interfaz WebSocket.

La función principal de afb-daemon se encuentra en el archivo main-afb-daemon.c. La lógica principal en su función principal hace cuatro cosas:

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

Teniendo en cuenta que el proceso daemon puede ser solicitado simultáneamente por varios clientes al mismo tiempo, afb-daemon funciona de manera multiproceso. En concreto, se implementa a través de la siguiente interfaz:

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

Varios parámetros aquí se explican de la siguiente manera:

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

Los valores establecidos para estos parámetros en la función principal son los siguientes:

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

(11)afm-util

El marco de la aplicación proporciona una herramienta de línea de comandos para facilitar el desarrollo y las pruebas, el nombre de esta herramienta se llama afm-util.

Las funciones proporcionadas incluyen lo siguiente:

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) Marco de interfaz hombre-máquina

El marco de interfaz hombre-máquina (HMI) incluye principalmente los siguientes módulos:

WindowManager
HomeScreen
SoundManager
InputManager

Administrador de ventanas

  • WindowManager Como su nombre indica, este módulo se encarga de la gestión de ventanas del sistema. El código fuente se puede obtener con el siguiente comando:
git clone https://gerrit.automotivelinux.org/gerrit/apps/agl-service-windowmanager

El hardware que necesita administrar WindowManager incluye: dispositivo de visualización, GPU, dispositivo de entrada y memoria de video. Sus principales responsabilidades incluyen:

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

La siguiente es solo una breve introducción a este módulo.
La arquitectura general de WindowManager se muestra en la siguiente figura:
inserte la descripción de la imagen aquí
El módulo WindowManager consta de cuatro partes:

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

Las aplicaciones pueden usar libwindowmanager.so para usar la interfaz WindowManager. Las interfaces incluyen lo siguiente:

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);

La implementación del módulo de escritorio HomeScreen
está contenida en los siguientes proyectos:

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

inserte la descripción de la imagen aquí

libhomescreen proporciona un conjunto de interfaces para administrar el escritorio: para obtener una descripción de estas interfaces, consulte el archivo 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);

Por ejemplo, cuando se hace clic en una aplicación, se llamará a la interfaz showWindow para mostrar la aplicación afectada:

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) Instalar virtual-box en no WSL para iniciar el AGL existente

El primer paso es instalar vm en windows: vm 6.0.24 windows y paquetes de extensión ( tutorial de instalación )

Paso 2: Consulte 2. Virtual Box (Emulación) para instalar AGL en VM

pregunta:

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

resolver:

Existe un conflicto entre WSL y máquinas virtuales virtuales, vm, así que habilite el conmutador WSL de la siguiente manera:

bcdedit /set hypervisorlaunchtype off

Reinicia la computadora

Desactivar la compatibilidad con máquinas virtuales: referencia

Abierto:

bcdedit /set hypervisorlaunchtype auto

Reinicia la computadora

Motas:

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

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

1) Instalar caja virtual en no WSL2 : 6.0.24

方法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: Cómo instalar VirtualBox en Ubuntu 20.04 , Ubuntu: Solución al problema NO_PUBKEY (clave pública no encontrada)

Problemas con el Método 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.

Solución: Agregue este O_PUBKEY A2F683C52980AECF

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

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

2) Use virtualbox, siga el tutorial 2. Virtual Box (Emulación) para iniciar el archivo vmdk

启动virtualbox:

Problemas con el Método 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.

Resuelto :

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

Problemas con el Método 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.

resolver:

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

Problemas con el Método 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.

resolver:

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.

Problemas con el Método 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.

resolver:

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

4. Desarrollo de aplicaciones AGL

El sistema AGL admite aplicaciones web y aplicaciones nativas. El marco del sistema se encargará de la gestión de diferentes tipos de aplicaciones.

Obviamente, la imagen del sistema correspondiente debe obtenerse antes del desarrollo de la aplicación AGL. Si no tiene su propio entorno de compilación, puede descargar la imagen compilada del sitio web oficial .

Hay dos modos de desarrollo de aplicaciones AGL:

  • Use el kit de desarrollo de software (SDK para abreviar)
  • Utilice el sistema de desarrollo cruzado (XDS para abreviar)

XDS es la forma oficialmente recomendada. XDS admite la creación, implementación y ejecución de proyectos personales en el sistema de destino a través del panel de XDS o la línea de comandos de XDS.

Consulte aquí para obtener información sobre cómo desarrollar aplicaciones AGL: Guías para desarrolladores.

5. Hipervisor QNX

Como se mencionó anteriormente, el sistema QNX de BlackBerry tiene la participación más alta en el mercado IVI actual. Esto se debe principalmente a sus características de seguridad y estabilidad.

Sin embargo, QNX en sí mismo es un software comercial pago y no es de código abierto, por lo que es más difícil personalizarlo en profundidad.

Afortunadamente, el sistema QNX tiene una función de hipervisor, que es similar a la función de máquina virtual en una computadora: ejecuta otros sistemas operativos basados ​​en QNX, como los sistemas Linux o Android. Como se muestra abajo:
inserte la descripción de la imagen aquí

árbitro:

Supongo que te gusta

Origin blog.csdn.net/u011436427/article/details/129855704
Recomendado
Clasificación