Directorio de artículos
- 1. Tipo de controlador de coche
- dos, hipervisor
- 3. QNX, Linux, Android
- 4. Linux de grado automotriz (AGL)
-
- 1. Introducción
- 2. Situación actual del mercado IVI
- 3. Construcción del sistema
-
- (1) El sistema host a desarrollar
- (2) Descargue el entorno de compilación AGL
- (3) Inicializar el entorno de compilación
- (4) compilar la imagen del sistema
- (5) Inicie el producto compilado
- (6) Arquitectura del sistema
- (7) Explorar el código fuente
- (8) Marco de aplicación
- (9) afm-user-daemon
- (10)afb-demonio
- (11)afm-util
- (12) Marco de interfaz hombre-máquina
- (13) Instalar virtual-box en no WSL para iniciar el AGL existente
- 4. Desarrollo de aplicaciones AGL
- 5. Hipervisor QNX
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)
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. . .
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.
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.
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:
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:
3. Construcción del sistema
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:
(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:
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, repo
lo 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 CMake
como 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-daemon
y afm-user-daemon
dos módulos. Estos son dos procesos separados que D-Bus
se 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)
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-daemon
Las configuraciones de inicio de y afm-user-daemon
son 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-daemon
Iniciado por/usr/bin/afb-daemon
el ejecutable.afm-user-daemon
Iniciado 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:
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:
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
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
- Tenga en cuenta que wsl no es compatible con virtualbox, consulte lo siguiente
方法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:
árbitro: