Como implantar rapidamente aplicações de aprendizagem de máquinas prontas para a borda

O aprendizado de máquinas (ML) oferece um tremendo potencial para a criação de produtos inteligentes, mas a complexidade e os desafios envolvidos na modelagem de redes neurais (NN) e na criação de aplicações ML para a borda têm limitado a capacidade dos desenvolvedores de entregar rapidamente soluções úteis. Embora ferramentas prontamente disponíveis tenham tornado a criação do modelo ML mais acessível em geral, as práticas convencionais de desenvolvimento ML não são projetadas para atender às exigências exclusivas de soluções para a Internet das Coisas (IoT), automóveis, sistemas industriais e outras aplicações embarcadas.

Este artigo fornece uma breve introdução à modelagem NN. Em seguida, apresenta e descreve como usar uma plataforma ML abrangente da NXP Semiconductors que permite que os desenvolvedores ofereçam aplicações ML mais eficientes e prontas para a borda.

Uma rápida revisão da modelagem NN

Os algoritmos ML oferecem aos desenvolvedores uma opção drasticamente diferente para o desenvolvimento de aplicações. Em vez de escrever código de software destinado a resolver explicitamente problemas como classificação de imagens, os desenvolvedores treinam modelos NN apresentando um conjunto de dados como imagens anotadas com o nome real (ou classe) da entidade contida na imagem. O processo de treinamento utiliza uma variedade de métodos para calcular os parâmetros de pesos e valores de polarização de um modelo para cada neurônio e camada, respectivamente, permitindo que o modelo forneça uma previsão razoavelmente precisa da classe correta de uma imagem de entrada (Figura 1).

Figura 1: NNs como esta rede totalmente conectada classificam um objeto de entrada usando parâmetros de peso e polarização definidos durante o treinamento. (Fonte da imagem: NXP Semiconductors)

Os pesquisadores de ML desenvolveram uma ampla gama de arquiteturas NN, além da NN genérica totalmente conectada mostrada na Figura 1. Por exemplo, as aplicações de classificação de imagens normalmente utilizam a NN convolucional (CNN), uma arquitetura especializada que divide o reconhecimento de imagens em uma fase inicial que encontra características principais de uma imagem, seguida por uma fase de classificação que prevê a probabilidade de que ela pertença a uma das várias classes estabelecidas durante o treinamento (Figura 2).

Figura 2: Os especialistas de ML utilizam arquiteturas NN especializadas como esta rede neural convolucional (CNN) para tarefas específicas como o reconhecimento de imagens. (Fonte da imagem: NXP Semiconductors)

Embora a seleção de uma arquitetura apropriada de modelo e um regime de treinamento tenha sido limitado aos especialistas do ML, a disponibilidade de múltiplas ferramentas comerciais e de código aberto simplificou drasticamente o desenvolvimento de modelos para implantações em larga escala. Hoje, os desenvolvedores podem definir modelos com algumas linhas de código (listagem 1), e usar ferramentas como o visualizador de modelos Netron de código aberto para gerar uma representação gráfica do modelo (Figura 3) para verificar cada camada de definição e conectividade.

Copiar
def model_create(shape_in, shape_out):
    from keras.regularizers import l2
    
    tf.random.set_seed(RANDOM_SEED)
 
    model = tf.keras.Sequential()
    model.add(tf.keras.Input(shape=shape_in, name='acceleration'))
    model.add(tf.keras.layers.Conv2D(8, (4, 1), activation='relu'))
    model.add(tf.keras.layers.Conv2D(8, (4, 1), activation='relu'))
    
    model.add(tf.keras.layers.Dropout(0.5))
    
    model.add(tf.keras.layers.MaxPool2D((8, 1), padding='valid'))
    model.add(tf.keras.layers.Flatten())
    
    model.add(tf.keras.layers.Dense(64, kernel_regularizer=l2(1e-4), bias_regularizer=l2(1e-4), activation='relu'))
    model.add(tf.keras.layers.Dropout(0.5))
    model.add(tf.keras.layers.Dense(32, kernel_regularizer=l2(1e-4), bias_regularizer=l2(1e-4), activation='relu'))
    model.add(tf.keras.layers.Dropout(0.5))
    model.add(tf.keras.layers.Dense(shape_out, activation='softmax'))
    model.compile(optimizer='adam', loss='categorical_crossentropy', metrics=['acc'])
    
    return model

Listagem 1: Os desenvolvedores podem definir modelos NN usando apenas algumas linhas de código. (Fonte do código: NXP Semiconductors)

Figura 3: Gerado pelo visualizador Netron, esta representação gráfica do modelo definido na Listagem 1 pode ajudar o desenvolvedor a documentar a função e a conectividade de cada camada. (Fonte da imagem: Stephen Evanczuk, rodando Netron no código fonte do modelo NXP na Listagem 1)

Para a implantação final, outras ferramentas retiram as estruturas do modelo necessárias apenas durante o treinamento e realizam outras otimizações para criar um modelo de inferência eficiente.

Por que desenvolver aplicações baseadas em ML para produtos inteligentes tem sido tão difícil

A definição e o treinamento de um modelo para o IoT ou outros produtos inteligentes seguem um fluxo de trabalho semelhante ao da criação de um modelo para aplicações de aprendizagem de máquinas em escala empresarial. Além dessa similaridade, porém, o desenvolvimento de aplicações ML para a borda traz múltiplos desafios adicionais. Junto com o desenvolvimento de modelos, os projetistas enfrentam os desafios familiares de desenvolver a principal aplicação necessária para executar seu produto baseado em microcontrolador (MCU). Como resultado, trazer o ML para a borda exige o gerenciamento de dois fluxos de trabalho inter-relacionados (Figura 4).

Figura 4: O desenvolvimento de uma aplicação baseada em ML para a borda estende o típico fluxo de trabalho de desenvolvimento MCU embarcado com um fluxo de trabalho ML necessário para treinar, validar e implantar um modelo ML. (Fonte da imagem: NXP Semiconductors)

Embora o fluxo de trabalho do projeto MCU seja familiar aos desenvolvedores de dispositivos embarcados, o projeto ML pode impor requisitos adicionais à aplicação baseada no MCU, uma vez que os desenvolvedores trabalham para criar um modelo otimizado de inferência ML. Na verdade, o projeto ML tem um impacto dramático nas exigências do dispositivo embarcado. A pesada carga computacional e os requisitos de memória normalmente associados à execução do modelo podem exceder os recursos dos microcontroladores usados no IoT e nos produtos inteligentes. Para reduzir os requisitos de recursos, os especialistas de ML aplicam técnicas como poda da rede modelo, compressão, quantização para menor precisão, ou mesmo parâmetros de bit único e valores intermediários, e outros métodos.

Mesmo com estes métodos de otimização, porém, os desenvolvedores ainda podem encontrar microcontroladores convencionais que não têm o desempenho necessário para lidar com o grande número de operações matemáticas associadas aos algoritmos ML. Por outro lado, o uso de um processador de aplicação de alto desempenho poderia lidar com a carga computacional ML, mas essa abordagem poderia resultar em maior latência e resposta não determinística, degradando as características em tempo real de seu projeto embarcado.

Além dos desafios de seleção de hardware, o fornecimento de modelos ML otimizados para a borda tem desafios adicionais exclusivos do desenvolvimento embarcado. O vasto número de ferramentas e métodos desenvolvidos para aplicações ML em escala empresarial pode não se adaptar bem à aplicação e ao ambiente operacional do desenvolvedor de embarcados. Mesmo desenvolvedores experientes que esperam implantar rapidamente dispositivos baseados em ML podem encontrar dificuldades para achar uma solução eficaz entre uma riqueza de arquiteturas disponíveis de modelo NN, ferramentas, estruturas e fluxos de trabalho.

A NXP aborda tanto o desempenho do hardware quanto as facetas de implementação de modelos do desenvolvimento ML de borda. No nível de hardware, os microcontroladores crossover de alto desempenho i.MX RT1170 da NXP atendem aos amplos requisitos de desempenho da ML de borda. Para tirar o máximo proveito desta base de hardware, o ambiente do desenvolvimento de software eIQ (edge intelligence) ML da NXP e os pacotes de software de aplicação oferecem aos desenvolvedores inexperientes e especialistas ML uma solução eficaz para a criação de aplicações ML prontas para a borda.

Uma plataforma eficaz para o desenvolvimento de aplicações ML prontas para a borda

Os processadores crossover i.MX RT da NXP combinam a resposta em tempo real e de baixa latência dos microcontroladores embarcados tradicionais com as capacidades de execução dos processadores de aplicação de alto desempenho. A série de processadores crossover i.MX RT1170 da NXP integra um processador Cortex®-M4 da Arm® de eficiência energética e um processador Cortex-M7 da Arm de alto desempenho com um extenso conjunto de blocos funcionais e periféricos necessários para executar aplicações exigentes, incluindo soluções baseadas em ML em dispositivos embarcados (Figura 5).

Figura 5: Os processadores crossover i.MX RT1170 da NXP combinam a capacidade de eficiência energética dos microcontroladores convencionais com a capacidade de processamento de alto desempenho dos processadores de aplicação. (Fonte da imagem: NXP Semiconductors)

Totalmente integrado aos ambientes de desenvolvimento MCUXpresso SDK e Yocto da NXP, o ambiente NXP eIQ foi projetado especificamente para facilitar a implementação de modelos de inferência em sistemas embarcados construídos com microprocessadores e microcontroladores NXP. Incluído no ambiente eIQ, o eIQ Toolkit suporta fluxo de trabalho que trazem seus próprios dados (BYOD) e trazem seu próprio modelo BYOM através de várias ferramentas, incluindo o eIQ Portal, a eIQ Model Tool e as ferramentas de linha de comando (Figura 6).

Figura 6: O NXP eIQ Toolkit suporta desenvolvedores BYOD que precisam criar um modelo e desenvolvedores BYOM que precisam implantar seu próprio modelo existente em um sistema alvo. (Fonte da imagem: NXP Semiconductors)

Projetado para suportar fluxos de trabalho BYOD para especialistas e desenvolvedores novos no desenvolvimento do modelo ML, o eIQ Portal fornece uma interface gráfica do usuário (GUI) que ajuda os desenvolvedores a completar mais facilmente cada etapa do fluxo de trabalho de desenvolvimento do modelo.

Na etapa inicial de desenvolvimento, a ferramenta curadora do conjunto de dados do eIQ Portal ajuda os desenvolvedores a importar dados, capturar dados de uma câmera conectada ou capturar dados de um dispositivo remoto (Figura 7).

Figura 7: A ferramenta curadora do conjunto de dados do eIQ Portal facilita a tarefa crítica de preparação dos dados de treinamento. (Fonte da imagem: NXP Semiconductors)

Usando a ferramenta curadora do conjunto de dados, os desenvolvedores anotam, ou rotulam, cada item do conjunto de dados etiquetando a imagem inteira, ou apenas regiões específicas contidas dentro de uma caixa de delimitação especificada. Um recurso de ampliação ajuda os desenvolvedores a fornecer a diversidade necessária para o conjunto de dados ao embaçar imagens, adicionar ruído aleatório, mudar características como brilho ou contraste, e outros métodos.

Na fase seguinte, o eIQ Portal ajuda os desenvolvedores a selecionar o tipo de modelo mais adequado para a aplicação. Para os desenvolvedores incertos quanto ao tipo de modelo, um assistente de seleção de modelo conduz os desenvolvedores através do processo de seleção com base no tipo de aplicação e na base de hardware. Os desenvolvedores que já sabem que tipo de modelo precisam, podem selecionar um modelo personalizado fornecido com a instalação do eIQ ou outras implementações personalizadas.

O eIQ Portal leva os desenvolvedores através da próxima etapa crítica de treinamento, fornecendo uma GUI intuitiva para modificar os parâmetros de treinamento e visualizar as mudanças na precisão da previsão do modelo com cada etapa de treinamento (Figura 8).

Figura 8: Os desenvolvedores utilizam a ferramenta de treinamento do eIQ Portal para observar melhorias na precisão do treinamento a cada passo, e para modificá-las se necessário. (Fonte da imagem: NXP Semiconductors)

No próximo passo, a GUI do eIQ Portal ajuda os desenvolvedores a validar o modelo. Nesta etapa, o modelo é convertido para ser executado na arquitetura de destino para determinar seu desempenho real. Quando a validação é concluída, a tela de validação exibe a matriz de confusão — uma ferramenta ML fundamental de validação que permite aos desenvolvedores comparar a classe real do objeto de entrada com a classe prevista pelo modelo (Figura 9).

Figura 9: A ferramenta de validação do eIQ Portal fornece aos desenvolvedores a matriz de confusão resultante da execução de um modelo em uma arquitetura de destino. (Fonte da imagem: NXP Semiconductors)

Para a implantação final, o ambiente oferece aos desenvolvedores uma escolha de motores de inferência alvo dependendo do processador, incluindo:

• Arm CMSIS-NN (Common Microcontroller Software Interface Standard, Neural Network) — kernels de redes neurais desenvolvidos para maximizar o desempenho e minimizar o espaço de memória das redes neurais nos núcleos de processadores Arm Cortex-M
• Arm NN SDK (rede neural, kit de desenvolvimento de software) — um conjunto de ferramentas e motor de inferência projetado para fazer a ponte entre as estruturas de rede neural existentes e os processadores Arm Cortex-A, entre outros
• DeepViewRT — Motor de inferência proprietário da NXP para MCUs crossover i.MX RT
• Glow NN — Baseado no compilador Glow ("graph lowering") da Meta e otimizado pela NXP para núcleos Arm Cortex-M usando chamadas de função para kernels CMSIS-NN ou a biblioteca NN da Arm, se disponível, caso contrário compilando código de sua própria biblioteca nativa
• ONXX Runtime — Ferramentas da Microsoft Research projetadas para otimizar o desempenho dos processadores Arm Cortex-A.
• TensorFlow Lite for Microcontrollers — Uma versão menor do TensorFlow Lite, otimizado para executar modelos de aprendizagem de máquinas em MCUs crossover i.MX RT
• TensorFlow Lite — Uma versão do TensorFlow que fornece suporte para sistemas menores

Para fluxos de trabalho BYOM, os desenvolvedores podem usar o eIQ Model Tool para passar diretamente à análise do modelo e ao perfil de tempo por camada. Tanto para os fluxos de trabalho BYOD como BYOM, os desenvolvedores podem usar as ferramentas de linha de comando eIQ, que fornecem acesso à funcionalidade da ferramenta, bem como recursos não disponíveis do eIQ diretamente através da GUI.

Além dos recursos descritos neste artigo, o eIQ Toolkit suporta um amplo conjunto de capacidades, incluindo conversão e otimização de modelos que está muito além do escopo deste artigo. Entretanto, para a prototipagem rápida de aplicações ML prontas para a borda, os desenvolvedores podem geralmente avançar rapidamente através do desenvolvimento e implantação com pouca necessidade de empregar muitas das capacidades mais sofisticadas do ambiente eIQ. De fato, os pacotes especializados de software de aplicação (App SW) da NXP oferecem aplicações completas que os desenvolvedores podem usar para avaliação imediata, ou como base de suas próprias aplicações personalizadas.

Como avaliar rapidamente o desenvolvimento de modelos usando um pacote App SW

Os pacotes App SW da NXP fornecem uma aplicação completa baseada em ML, combinando código fonte pronto para produção, drivers, middleware e ferramentas. Por exemplo, o pacote App SW ML State Monitor oferece uma solução imediata baseada na ML para o problema frequente de determinar o estado de sistemas complexos com base em entradas de sensores (Figura 10).

Figura 10: Os desenvolvedores podem usar os pacotes App SW da NXP tais como o pacote App SW ML State Monitor para avaliação imediata, ou como base para o desenvolvimento de códigos personalizados. (Fonte da imagem: NXP Semiconductors)

O pacote App SW ML State Monitor App implementa uma solução completa para uma aplicação destinada a detectar quando uma ventoinha está operando em um dos quatro estados:

• ON
• OFF
• CLOGGED, quando a ventoinha está ligada mas o fluxo de ar está obstruído
• FRICTION, quando a ventoinha está ligada, mas uma ou mais pás da ventoinha estão enfrentando atrito em excesso durante a operação

Igualmente importante para os desenvolvedores de modelos, o pacote App SW ML State Monitor inclui modelos ML, bem como um conjunto completo de dados que representam leituras de acelerômetros de uma ventoinha operando em cada um desses quatro estados.

Os desenvolvedores podem estudar códigos, modelos e dados fornecidos no pacote App SW ML State Monitor para entender como usar os dados do sensor para treinar um modelo, criar um modelo de inferência, e validar a inferência contra um conjunto de dados de validação do sensor. Na verdade, o ML_State_Monitor.ipynb Jupyter Notebook da NXP, incluído no pacote App SW, fornece uma ferramenta imediata e pronta para estudar o fluxo de trabalho de desenvolvimento do modelo bem antes de qualquer implantação de hardware.

O Jupyter Notebook é uma plataforma Python de execução interativa baseada em navegador que permite aos desenvolvedores visualizar imediatamente os resultados da execução do código Python. A execução de Jupyter Notebook gera um bloco de código Python, imediatamente seguido pelos resultados da execução desse bloco de código. Estes resultados não são simplesmente mostradores estáticos, mas são os resultados reais obtidos com a execução do código. Por exemplo, quando os desenvolvedores executam o ML_State_Monitor.ipynb Jupyter Notebook da NXP, eles podem ver imediatamente um resumo do conjunto de dados de entrada (Figura 11).

Figura 11: O ML_State_Monitor.ipynb Jupyter Notebook da NXP permite que os desenvolvedores trabalhem interativamente através do fluxo de trabalho de desenvolvimento do modelo de rede neural, visualizando os dados de treinamento fornecidos no pacote App SW ML State Monitor App. [Observação: código truncado aqui para fins de exibição]. (Fonte da imagem: Stephen Evanczuk, executando o ML_State_Monitor.ipynb Jupyter Notebook da NXP)

A seção seguinte do código no Notebook fornece ao usuário uma exibição gráfica dos dados de entrada, apresentados como gráficos separados para sequência de tempo e de frequência (Figura 12).

Figura 12: O Jupyter Notebook fornece aos desenvolvedores exibições de séries temporais e de frequência do conjunto de dados do estado da ventoinha como amostras (OFF: verde; ON: vermelho; CLOGED: azul; FRICTION: amarelo). [Observação: código truncado para fins de apresentação]. (Fonte da imagem: Stephen Evanczuk, executando o ML_State_Monitor.ipynb Jupyter Notebook da NXP)

Outras seções de códigos fornecem análise de dados adicionais, normalização, modelagem e outras preparações até que a execução do código atinja a mesma definição da função de criação do modelo, model_create(), mostrada anteriormente na Listagem 1. A próxima seção de código executa esta função model_create() e imprime um resumo para validação rápida (Figura 13).

Figura 13: O ML_State_Monitor.ipynb Jupyter Notebook da NXP cria o modelo (mostrado na Listagem 1) e exibe as informações resumidas do modelo. (Fonte da imagem: Stephen Evanczuk, executando o ML_State_Monitor.ipynb Jupyter Notebook da NXP)

Seguindo uma seção de código para treinamento e avaliação do modelo, o ML_State_Monitor.ipynb Jupyter Notebook exibe cada matriz de confusão para o conjunto de dados completos, o conjunto de dados de treinamento e o conjunto de dados de validação (um subconjunto do conjunto de dados excluído do conjunto de dados de treinamento). Neste caso, a matriz de confusão para o conjunto de dados completos mostra boa precisão com alguma quantidade de erro, principalmente quando o modelo confunde uma pequena porcentagem dos conjuntos de dados como estando no estado ON quando estão na verdade no estado CLOGGED, como anotado no conjunto de dados original (Figura 14).

Figura 14: Os desenvolvedores podem visualizar matrizes de confusão como esta, para o conjunto de dados completos. (Fonte da imagem: Stephen Evanczuk, executando o ML_State_Monitor.ipynb Jupyter Notebook da NXP)

Em uma seção de código posterior, o modelo é exportado para vários tipos e formatos diferentes de modelos utilizados pelos vários motores de inferência suportados pelo ambiente de desenvolvimento do eIQ (Figura 15).

Figura 15: O ML_State_Monitor.ipynb Jupyter Notebook da NXP demonstra como os desenvolvedores podem salvar seus modelos treinados em vários tipos e formatos diferentes de modelos. (Fonte da imagem: Stephen Evanczuk, executando o ML_State_Monitor.ipynb Jupyter Notebook da NXP)

A escolha do motor de inferência pode ser criticamente importante para atender às exigências específicas de desempenho. Para esta aplicação, o modelo NXP mediu o tamanho do modelo, o tamanho do código e o tempo de inferência (tempo necessário para completar a inferência em um único objeto de entrada) quando o modelo é direcionado a vários motores de inferência, um rodando a 996 megahertz (MHz) e outro rodando a 156 MHz (Figuras 16 e 17).

Figura 16: A escolha do tipo de modelo pode ter um impacto dramático no tamanho do modelo, embora as diferenças dramáticas mostradas aqui talvez não se apliquem a modelos maiores. (Fonte da imagem: NXP Semiconductors)

Figura 17: O tempo de inferência pode diferir significativamente para avaliação de um objeto de entrada quando carregado da memória RAM ou flash, ou quando se opera o processador a uma frequência mais alta de 996 MHz contra 156 MHz. (Fonte da imagem: NXP Semiconductors)

Como a NXP observa, esta aplicação de amostra utiliza um modelo muito pequeno, portanto, as diferenças bastante acentuadas mostradas nestes números podem ser substancialmente menos pronunciadas em um modelo maior utilizado para classificações complexas.

Construindo uma solução de sistema para monitoramento de estado

Além do Jupyter Notebook para exploração interativa do fluxo de trabalho de desenvolvimento do modelo, o pacote App SW ML State Monitoring da NXP fornece o código fonte completo para implementação do projeto na placa de avaliação MIMXRT1170-EVK da NXP. Construído em torno de um MCU crossover MIMXRT1176DVMAA da NXP, a placa de avaliação fornece uma plataforma de hardware abrangente, completa com memória adicional e múltiplas interfaces (Figura 18).

Figura 18: A placa de avaliação MIMXRT1170-EVK da NXP fornece uma plataforma de hardware abrangente para o desenvolvimento de aplicações baseadas no MCU crossover NXP i.MX série RT1170. (Fonte da imagem: NXP Semiconductors)

Os desenvolvedores podem usar a aplicação do estado da ventoinha da NXP para prever o estado de uma ventoinha, empilhando a placa de avaliação MIMXRT1170-EVK com uma placa de sensor opcional FRDM-STBC-AGM01 da NXP, um Arduino shield e uma ventoinha CC adequada sem escovas de 5 volts, como o 4468 da Adafruit (Figura 19).

Figura 19: Os desenvolvedores podem testar a aplicação da amostra da NXP para o estado da ventoinha com uma simples pilhagem construída sobre a placa de avaliação MIMXRT1170-EVK. (Fonte da imagem: NXP Semiconductors)

Usando o ambiente de desenvolvimento integrado (IDE) MCUXpresso, os desenvolvedores podem configurar a aplicação para simplesmente adquirir e armazenar os dados do estado da ventoinha, ou executar imediatamente a inferência sobre os dados adquiridos usando um motor de inferência TensorFlow, motor de inferência DeepViewRT ou motor de inferência Glow (Listagem 2).

Copiar
/* Action to be performed */
#define SENSOR_COLLECT_LOG_EXT                  1   // Collect and log data externally
#define SENSOR_COLLECT_RUN_INFERENCE            2   // Collect data and run inference
 
/* Inference engine to be used */
#define SENSOR_COLLECT_INFENG_TENSORFLOW        1   // TensorFlow
#define SENSOR_COLLECT_INFENG_DEEPVIEWRT        2   // DeepViewRT
#define SENSOR_COLLECT_INFENG_GLOW              3   // Glow
 
/* Data format to be used to feed the model */
#define SENSOR_COLLECT_DATA_FORMAT_BLOCKS       1   // Blocks of samples
#define SENSOR_COLLECT_DATA_FORMAT_INTERLEAVED  2   // Interleaved samples
 
 
/* Parameters to be configured by the user: */
/* Configure the action to be performed */
#define SENSOR_COLLECT_ACTION                   SENSOR_COLLECT_RUN_INFERENCE
 
#if SENSOR_COLLECT_ACTION == SENSOR_COLLECT_LOG_EXT
/* If the SD card log is not enabled the sensor data will be streamed to the terminal */
#define SENSOR_COLLECT_LOG_EXT_SDCARD           1   // Redirect the log to SD card, otherwise print to console

Lista 2: Os desenvolvedores podem facilmente configurar a aplicação de amostra ML State Monitor da NXP, modificando as definições incluídas no arquivo de cabeçalho sensor_collect.h. (Fonte do código: NXP Semiconductors)

A aplicação opera com um fluxo de processo simples. A rotina principal em main.c cria uma tarefa chamada MainTask, que é uma rotina localizada no módulo sensor_collect.c.

Copiar
void MainTask(void *pvParameters)
{
    status_t status = kStatus_Success;
 
    printf("MainTask started\r\n");
 
#if !SENSOR_FEED_VALIDATION_DATA
    status = SENSOR_Init();
    if (status != kStatus_Success)
    {
        goto main_task_exit;
    }
#endif
 
    g_sensorCollectQueue = xQueueCreate(SENSOR_COLLECT_QUEUE_ITEMS, sizeof(sensor_data_t));
    if (NULL == g_sensorCollectQueue)
    {
        printf("collect queue create failed!\r\n");
        status = kStatus_Fail;
        goto main_task_exit;
    }
 
#if SENSOR_COLLECT_ACTION == SENSOR_COLLECT_LOG_EXT
    uint8_t captClassLabelIdx;
    CAPT_Init(&captClassLabelIdx, &g_SensorCollectDuration_us, &g_SensorCollectDuration_samples);
    g_SensorCollectLabel = labels[captClassLabelIdx];
 
    if (xTaskCreate(SENSOR_Collect_LogExt_Task, "SENSOR_Collect_LogExt_Task", 4096, NULL, configMAX_PRIORITIES - 1, NULL) != pdPASS)
    {
        printf("SENSOR_Collect_LogExt_Task creation failed!\r\n");
        status = kStatus_Fail;
        goto main_task_exit;
    }
#elif SENSOR_COLLECT_ACTION == SENSOR_COLLECT_RUN_INFERENCE
    if (xTaskCreate(SENSOR_Collect_RunInf_Task, "SENSOR_Collect_RunInf_Task", 4096, NULL, configMAX_PRIORITIES - 1, NULL) != pdPASS)
    {
        printf("SENSOR_Collect_RunInf_Task creation failed!\r\n");
        status = kStatus_Fail;
        goto main_task_exit;
    }
#endif

Listagem 3: Na aplicação de amostra ML State Monitor da NXP, a MainTask invoca uma subtarefa para adquirir dados ou executar inferências. (Fonte do código: NXP Semiconductors)

MainTask executa várias tarefas de inicialização antes de lançar uma das duas subtarefas, dependendo das definições configuradas pelo usuário no sensor_collect.h:

• se SENSOR_COLLECT_ACTION estiver configurado para SENSOR_COLLLECT_LOG_EXT, MainTask inicia a subtarefa SENSOR_Collect_LogExt_Task(), que coleta dados e os armazena no cartão SD, se estiver configurado
• se SENSOR_COLLECT_ACTION estiver configurado como SENSOR_COLLECT_RUN_INFERENCE, MainTask inicia a subtarefa SENSOR_Collect_RunInf_Task(), que executa o motor de inferência (Glow, DeepViewRT ou TensorFlow) definido no sensor_collect.h em relação aos dados coletados, e se SENSOR_EVALUATE_MODEL estiver definido, exibe a previsão resultante de desempenho e classificação

Copiar
if SENSOR_COLLECT_ACTION == SENSOR_COLLECT_LOG_EXT
void SENSOR_Collect_LogExt_Task(void *pvParameters)
{
[code deleted for simplicity]
    while (1)
    {
[code deleted for simplicity]
            bufSizeLog = snprintf(buf, bufSize, "%s,%ld,%d,%d,%d,%d,%d,%d,%d\r\n", g_SensorCollectLabel, (uint32_t)(sensorData.ts_us/1000),
                    sensorData.rawDataSensor.accel[0], sensorData.rawDataSensor.accel[1], sensorData.rawDataSensor.accel[2],
                    sensorData.rawDataSensor.mag[0], sensorData.rawDataSensor.mag[1], sensorData.rawDataSensor.mag[2],
                    sensorData.temperature);
 
#if SENSOR_COLLECT_LOG_EXT_SDCARD
                SDCARD_CaptureData(sensorData.ts_us, sensorData.sampleNum, g_SensorCollectDuration_samples, buf, bufSizeLog);
#else
                printf("%.*s", bufSizeLog, buf);
[code deleted for simplicity]
    }
 
    vTaskDelete(NULL);
}
#elif SENSOR_COLLECT_ACTION == SENSOR_COLLECT_RUN_INFERENCE
[code deleted for simplicity]
 
void SENSOR_Collect_RunInf_Task(void *pvParameters)
{
[code deleted for simplicity]
    while (1)
    {
[code deleted for simplicity]
                /* Run Inference */
                tinf_us = 0;
                SNS_MODEL_RunInference((void*)g_clsfInputData, sizeof(g_clsfInputData), (int8_t*)&predClass, &tinf_us, SENSOR_COLLECT_INFENG_VERBOSE_EN);
 
[code deleted for simplicity]
#if SENSOR_EVALUATE_MODEL
                /* Evaluate performance */
                validation.predCount++;
                if (validation.classTarget == predClass)
                {
                    validation.predCountOk++;
                }
                PRINTF("\rInference %d?%d | t %ld us | count: %d/%d/%d | %s      ",
                       validation.classTarget, predClass, tinf_us, validation.predCountOk,
                       validation.predCount, validation.predSize, labels[predClass]);
 
                tinfTotal_us += tinf_us;
                if (validation.predCount >= validation.predSize)
                {
                    printf("\r\nPrediction Accuracy for class %s %.2f%%\r\n", labels[validation.classTarget],
                            (float)(validation.predCountOk * 100)/validation.predCount);
                    printf("Average Inference Time %.1f (us)\r\n", (float)tinfTotal_us/validation.predCount);
                    tinfTotal_us = 0;
                }
#endif
 
    }
 
exit_task:
    vTaskDelete(NULL);
}
#endif  /* SENSOR_COLLECT_ACTION */

Listagem 4: A aplicação de amostra ML State Monitor da NXP demonstra o padrão básico de projeto para a aquisição de dados do sensor e o funcionamento do motor de inferência selecionado sobre os dados adquiridos. (Fonte do código: NXP Semiconductors)

Como o pacote App SW ML State Monitor da NXP fornece código fonte completo junto com um conjunto completo de drivers e middleware necessários, os desenvolvedores podem facilmente estender a aplicação para adicionar recursos ou usá-la como ponto de partida para seu próprio desenvolvimento personalizado.

Conclusão

A implementação de ML na borda em produtos inteligentes no IoT e outras aplicações pode fornecer um conjunto poderoso de recursos, mas muitas vezes deixou os desenvolvedores em dificuldades para aplicar ferramentas e métodos ML desenvolvidos para aplicações em escala empresarial. Com a disponibilidade de uma plataforma de desenvolvimento NXP compreendendo processadores crossover e software especializado de desenvolvimento de modelos, tanto os especialistas quanto os desenvolvedores de ML, com pouca ou nenhuma experiência, podem criar mais efetivamente aplicações ML projetadas especificamente para atender às exigências de desempenho eficiente na borda.