Compartir vía

Sugerencias de diseño de aplicaciones principales de alto nivel

  • Artículo

Importante

Esta es la documentación de Azure Sphere (heredado). Azure Sphere (heredado) se retira el 27 de septiembre de 2027 y los usuarios deben migrar a Azure Sphere (integrado) en este momento. Use el selector de versiones situado encima de la TOC para ver la documentación de Azure Sphere (integrado).

Para crear una aplicación principal de alto nivel (HL) sobre bases sólidas, debe usar procedimientos recomendados fundamentales. A continuación se muestran los elementos más relevantes:

Las aplicaciones principales de alto nivel (HL) se ejecutan en contenedores en el sistema operativo Azure Sphere. Durante las revisiones de código y diseño de las soluciones de los clientes hemos encontrado varios problemas típicos con las aplicaciones HL-core. En este tema se describen las sugerencias de mejoras de diseño para solucionar estos problemas.

Aspectos básicos generales

Para crear una aplicación de HL-core sobre bases sólidas, debe usar procedimientos recomendados fundamentales. A continuación se muestran los elementos más relevantes:

  • Inicialización y terminación: asegúrese siempre de controlar la señal SIGTERM del sistema operativo Azure Sphere e inicialice y destruya correctamente todos los controladores (como los de periféricos) tras la salida, ya sea tras bloqueo o error. Para obtener más información, consulte Inicialización y finalización y la documentación de GNU sobre señales de terminación.
  • Usar siempre códigos de salida: asegurarse de que la aplicación HL-core siempre proporciona un código de retorno significativo tras la salida o el bloqueo (por ejemplo, el uso del controlador SIGTERM) es esencial para diagnosticar correctamente el comportamiento del dispositivo, especialmente desde la telemetría del volcado de memoria del dispositivo. Para obtener más información, consulte Códigos de salida y Recopilación e interpretación de datos de error.
  • Asegúrese de que los casos de error siempre dan lugar a una salida o bloqueo de la aplicación en lugar de en un estado de interbloqueo: la lógica de recuperación de errores elaborada puede ser productiva, ya que puede introducir errores o comportamientos resultantes de un interbloqueo o un estado difícil de diagnosticar. Una aplicación de Azure Sphere bien diseñada siempre debe preferir bloqueos o salidas (con un código de salida distinto de cero) a una posible situación de interbloqueo, ya que esto da como resultado:
    • Telemetría de errores, habilitación de diagnósticos para este problema
    • Una posibilidad de recuperación inmediata a un estado de trabajo, ya que el sistema operativo Azure Sphere reiniciará la aplicación.
  • Control y registro de errores: el control y el registro precisos de errores están en el núcleo del desarrollo de aplicaciones de calidad. Las implementaciones rápidas de funcionalidad pueden permanecer enterradas en capas de código y, a continuación, se compilan a medida que la aplicación se desarrolla a gran escala. Para obtener más información sobre los procedimientos recomendados, consulte Control de errores y registro.
  • Usar un temporizador del sistema como guardián: uno de los procedimientos recomendados más cruciales es implementar una devolución de llamada "temporizador de guardián" (muy similar a las de hardware disponibles en MCU sin sistema operativo) que realiza un seguimiento de los estados críticos de la aplicación, la detección de interbloqueos y la acción en consecuencia (por ejemplo, salir y enviar telemetría). Para obtener más información, consulte Uso de un temporizador del sistema como guardián.
  • Nunca implemente aplicaciones de producción que se hayan compilado como destino un conjunto de herramientas de versión beta: no se recomienda usar conjuntos de herramientas de versión beta porque no se puede garantizar que el subconjunto beta no cambie en versiones posteriores del sistema operativo. Los conjuntos de herramientas beta se publican únicamente para probar nuevas características con antelación de una versión oficial del SDK.

Administrar la simultaneidad

  • Use EventLoop siempre que sea posible: los subprocesos y los objetos de sincronización (es decir, las exclusión mutuas, los semáforos, etc.) se usan para realizar tareas casi simultáneas, pero dentro de los sistemas incrustados, estos son costosos en términos de uso de recursos del sistema. Por lo tanto, para mejorar el rendimiento, considere la posibilidad de usar epolls en lugar de subprocesos, para aquellas tareas que no son estrictamente críticas para el tiempo y no son sensibles al bloqueo mutuo. Consulte Applibs eventloop.h para obtener información sobre cómo supervisar y enviar eventos con EventLoop, incluidos ejemplos relacionados.
  • Buscar eficacia en las tareas simultáneas: es importante asegurarse de que las operaciones de bloqueo y los tiempos de espera se mantienen en un mínimo dentro de las devoluciones de llamada epoll; de lo contrario, todas las demás devoluciones de llamada epoll se verán afectadas.
  • Cuándo usar subprocesos (pthread): para escenarios específicos, como cuando las llamadas de bloqueo son inevitables, el uso de subprocesos puede ser beneficioso, aunque normalmente esos escenarios tendrían una duración limitada y se deberían limitar a tareas específicas. Por ejemplo, dado que el sistema operativo de Azure Sphere (en ejecución de Linux) no expone IRQ a aplicaciones de núcleo HL (solo está disponible para aplicaciones rt-core), el uso de una combinación de tareas epoll y pthread podría ser óptima para controlar, por ejemplo, una comunicación en serie descendente mientras descarga datos de Internet.

Importante

El sistema operativo Azure Sphere podría interrumpir las operaciones oportunas, especialmente cuando realiza la atestación del dispositivo, la comprobación de actualizaciones o la carga de telemetría. En el caso de las tareas de control críticas para el tiempo, considere la posibilidad de moverlas a los núcleos M4 y coordinarlas con un protocolo adecuado a través del buzón entre núcleos. Para obtener más información, consulte el ejemplo de comunicación entre núcleos.

Además de estas sugerencias, revise la documentación de Azure Sphere sobre eventos asincrónicos y simultaneidad.

Supervisión de la conectividad

Una aplicación principal de alto nivel (HL) bien diseñada debe implementar una tarea adecuada de comprobación de estado de conectividad, que debe basarse en una máquina de estado sólida que compruebe periódicamente el estado de la conexión a Internet (por ejemplo, mediante un temporizador epoll ) aprovechando la API de Networking_IsNetworkingReady . En algunos casos, puede usar la función Networking_GetInterfaceConnectionStatus, ya que proporciona un estado más detallado del estado de conectividad relacionado con una interfaz de red específica que la aplicación HL-core puede usar para abordar mejor su estado, aunque esto conlleva un costo, ya que no se recomienda llamarlo con más frecuencia que cada 90 segundos.

La devolución de llamada de la máquina de estado normalmente debe tener los siguientes atributos:

  • Ejecute lo más rápido posible.
  • Su intervalo de sondeo debe diseñarse cuidadosamente, en función del escenario de aplicación específico y los requisitos generales de la solución (como el tiempo constante, el retraso incremental, etc.).
  • Una vez que se detecta una desconexión, puede ser útil llamar a Networking_GetInterfaceConnectionStatus una vez para registrar el estado de la interfaz de red específica, que se puede usar para diagnosticar el problema y notificar al usuario a través de una interfaz de usuario (como LED, pantalla, terminal). Puede encontrar un ejemplo de este enfoque en el código principal del ejemplo DHCP de Azure Sphere.
  • Active un mecanismo (por ejemplo, a través de una variable global) que detenga todas las demás tareas de la aplicación de HL-core que realizan (o están vinculadas a) las comunicaciones de red para optimizar el consumo de recursos hasta que se restablezca una conexión.
  • cURL ha actualizado recientemente el comportamiento de devolución de llamada y las mejores prácticas. Aunque Azure Sphere ha realizado esfuerzos para garantizar que las versiones anteriores del comportamiento de cURL sigan funcionando según lo previsto, se recomienda seguir las instrucciones más recientes sobre seguridad y confiabilidad al usar curl_multi, ya que el uso de devoluciones de llamada recursivas puede dar lugar a bloqueos inesperados, interrupciones de conectividad y posibles vulnerabilidades de seguridad. Si timerCallback se activa con un tiempo de espera de 0 ms, vítelo como un tiempo de espera de 1 ms para evitar devoluciones de llamada recursivas. Asegúrese de llamar también a curl_multi_socket_action explícitamente al menos una vez después de seguir las llamadas a curl_multi_add_handle.

Además de las sugerencias anteriores, debe tener en cuenta los siguientes escenarios para la administración de energía:

  • Apague el chip de Azure Sphere después de enviar datos. Para más información, consulte Administración del estado de apagado para dispositivos de Azure Sphere.
  • Dado que varios problemas pueden derivar de tiempos de espera de retroceso exponenciales prolongados, es fundamental realizar un seguimiento del tiempo de actividad total y establecer un temporizador de apagado en un límite razonable para no purgar la batería en condiciones en las que la conectividad ya no sea posible debido a interrupciones externas u otros factores más allá del control de la aplicación.
  • Para controlar la supervisión de la conectividad durante las interrupciones, el transceptor Wi-Fi puede apagarse deshabilitando la wlan0 interfaz de red (consulte Networking_SetInterfaceState) y esperando hasta que vuelva a comprobar la conectividad, ahorrando aproximadamente 100mW.

Administración y uso de memoria

En las plataformas restringidas a memoria, las aplicaciones que realizan asignaciones de memoria frecuentes y desasignación de memoria podrían provocar que la administración de memoria del sistema operativo tenga dificultades con la eficacia, lo que provocaría una fragmentación excesiva y una ejecución de memoria. Específicamente en Azure Sphere MT3620, esto puede dar lugar a condiciones de memoria insuficientes que podrían desencadenar el asesino de OOM del grupo de sistemas operativos de Azure Sphere para iniciar.

Es comprensible que las aplicaciones se desarrollan a menudo a partir de una prueba de concepto inicial, que se vuelve más completa con las características necesarias para las versiones progresivas, y finalmente se descuidan las características secundarias que se incluyeron inicialmente. A continuación se muestran sugerencias y optimizaciones que han demostrado ser eficaces para muchos escenarios analizados en el campo:

  • Especialmente en las aplicaciones de HL-core que hacen uso intensivo de la memoria, es esencial realizar un seguimiento del uso de la memoria de la aplicación a través de la API de Azure Sphere, que se describe en Determinación del uso de RAM de la aplicación en tiempo de ejecución. Normalmente, esto se implementa en un guardián de epoll-timer y la aplicación reacciona en consecuencia a un uso inesperado de memoria para reiniciarse de una manera razonable; por ejemplo, salir con el código de salida adecuado.

    Varios clientes y asociados han encontrado que resulta útil usar la utilidad de seguimiento de memoria heap Tracker , que se publica en la Galería de Azure Sphere. Esta biblioteca vincula de forma transparente a una aplicación existente de HL-core y realiza un seguimiento de las asignaciones de memoria y sus punteros relacionados, lo que permite la detección simplificada de la mayoría de los casos de fugas de memoria y usos indebidos de puntero.

Importante

Esta práctica puede reducir aparentemente que el dispositivo no responde o los errores que a menudo se notifican desde el campo. Estos errores suelen deberse a pérdidas de memoria o saturaciones que no se controlan correctamente por la aplicación HL-core y llevan al asesino de OOM a apagar el proceso de la aplicación. Esto, junto con una conectividad deficiente que impide que el sistema operativo Azure Sphere envíe datos de telemetría, puede provocar posibles incidentes de campo, ya que solo se puede detectar el diagnóstico mediante la extracción de los registros de diagnóstico del sistema operativo Azure Sphere.

  • En las plataformas restringidas a memoria, generalmente es preferible evitar la asignación de memoria dinámica siempre que sea posible, especialmente dentro de las funciones llamadas con frecuencia. Esto reducirá considerablemente la fragmentación de memoria del montón y la probabilidad de errores posteriores de asignación de montón. Considere también un cambio de paradigma desde la asignación repetitiva de búferes de trabajo temporales para acceder directamente a la pila (para variables de tamaños razonables) o búferes asignados globalmente, lo que aumenta el tamaño (a través reallocde ) tras el desbordamiento (consulte Contenedores dinámicos y búferes). Si hay un requisito para descargar memoria, considere la posibilidad de aprovechar la memoria sin usar en los núcleos M4 (consulte Memoria disponible en Azure Sphere), que tienen 256KiB cada uno, con una aplicación ligera rt-core para el almacenamiento en caché de datos. Podrías usar tarjetas SD externas o flash. Puede encontrar ejemplos en los repositorios siguientes:

Siguiendo las sugerencias anteriores también puede ayudar a calcular y reservar la memoria necesaria para que la aplicación HL-core funcione a plena capacidad en todo su ciclo de vida, lo que le permite calcular mejor la superficie de memoria general de la aplicación para las optimizaciones de diseño posteriores. Para más información sobre cómo optimizar el uso de memoria en aplicaciones de núcleo HL, incluidas las características del sistema operativo de Azure Sphere y Visual Studio, consulte los artículos siguientes: