FMI e a mesma simulação em todo o lado
O modelo não deve desenvolver uma personalidade
Um modelo de simulação deve ser monótono de uma forma muito específica: mesma entrada, mesmo modelo, mesma saída. Isso parece óbvio até o modelo passar de uma estação de trabalho para um cluster, de um portátil para hardware-in-the-loop, de um compilador para outro, ou de uma ferramenta de fornecedor para um gabinete de segurança que não aprecia dança interpretativa. Então, pequenas diferenças numéricas tornam-se reuniões. Reuniões tornam-se folhas de cálculo de reconciliação. Folhas de cálculo de reconciliação tornam-se o cemitério onde boas tardes de engenharia vão morrer.
O FMI existe para tornar a troca de modelos e a co-simulação práticas entre ferramentas. A Functional Mock-up Interface dá às equipas uma forma padrão de empacotar e executar modelos, em vez de transportar manualmente código de integração frágil de um ambiente de simulação para o seguinte. Isso já é útil. Mas uma interface padrão não torna automaticamente a aritmética determinística. Os fluxos de trabalho tradicionais de FMI dependem frequentemente do comportamento de vírgula flutuante IEEE 754, de bibliotecas de plataforma, de escolhas de compilador, da ordem de execução e de diferenças de backend. Na maioria das vezes, isso é suficiente. Depois, deixa de ser, e a diferença é normalmente descoberta por alguém com um prazo e uma expressão que diz que o procurement prometeu que isto seria fácil.
O Dweve FMI ataca a parte aborrecida e cara: a reprodutibilidade. O site descreve uma implementação de FMI em Rust para Model Exchange e Co-Simulation com aritmética de vírgula fixa determinística, construída sobre o Numerus. A forma da implementação é mais ampla do que uma demonstração: um espaço de trabalho FMI com múltiplas crates, com representação de modelos, análise de esquemas, importação, exportação, runtime, solver, orquestração, memória, backends para CPU, GPU, FPGA, execução edge e distribuída, FFI, fuzzing, benchmarks, documentação e testes. Depende das crates do Numerus para aritmética de vírgula fixa e decimal, além da stack comum do Dweve para simulação, registo, tratamento de falhas, transporte, tensores e armazenamento.
O objetivo não é tornar a simulação mística. O objetivo é fazer com que o mesmo FMU deixe de contar histórias ligeiramente diferentes porque acordou numa máquina diferente.
O FMI dá o envelope, a aritmética ainda assina o cheque
Um FMU é um envelope útil. Transporta uma descrição do modelo, binários ou artefactos de código-fonte, recursos, variáveis, estados, relógios, dependências e metadados suficientes para outra ferramenta instanciar e avançar o modelo. O FMI 3.0 adiciona relógios mais ricos, execução agendada, tipagem de variáveis melhorada e mecanismos de co-simulação. O código-fonte do Dweve FMI está organizado em torno desse envelope: fmi-schema analisa e valida descrições de modelos, fmi-import carrega arquivos FMU, fmi-export constrói arquivos, fmi-model representa variáveis e estado do modelo, e fmi-runtime é responsável pelo ciclo de vida, acesso a variáveis, relógios, eventos, derivadas e guardar ou restaurar estado.
Esse envelope é necessário, mas não é suficiente. A aritmética subjacente ainda decide se uma execução é reprodutível. A documentação do runtime diz que a aritmética de vírgula fixa usa o Numerus Q31_32 para computação determinística. Os metadados do espaço de trabalho nomeiam Q31.32 como o formato fixo padrão, Dec64_6 como o formato decimal padrão e Q16.16 para o tempo. A página pública fala sobre os perfis Q31.32, Q16.16 e Dec64_6, com o MPFR usado como rota de referência. Isso dá ao projeto um contrato claro: a simulação de valores reais deve ser mapeada em perfis numéricos determinísticos, em vez de deixar cada backend improvisar.
Há aqui um ponto importante de honestidade. As APIs viradas para FMI e as superfícies de compatibilidade podem ainda aceitar ou emitir valores de vírgula flutuante, porque a norma e as ferramentas existentes assim o esperam. O que importa não é uma pureza teatral em todas as fronteiras. O que importa é que o caminho determinístico central é construído em torno de perfis de ponto fixo Numerus e de validação contra uma referência de alta precisão onde a comparação faz sentido. Os adaptadores de fronteira podem falar a linguagem exterior. O contrato interno não deve tornar-se um encolher de ombros.
O perfil numérico é uma decisão do modelo
O ponto fixo não é uma definição mágica. Um modelo que precisa de valores de tempo compactos, um modelo com intervalos físicos amplos e um modelo que reporta quantidades decimais não têm a mesma pressão. Q16.16, Q31.32 e Dec64_6 não são autocolantes para um diapositivo. São contratos diferentes sobre intervalo, resolução, representação e sobre onde os erros podem viver.
É aqui que as equipas de simulação costumam ser demasiado descuidadas. Tratam o comportamento numérico como uma propriedade da ferramenta, em vez de uma propriedade do modelo. Depois a ferramenta muda, ou o backend muda, ou o modelo é embutido, e de repente a antiga suposição torna-se um fardo de validação. O Dweve FMI torna o perfil numérico parte da arquitetura, em vez de meteorologia de fundo. Isso é menos glamoroso do que uma grande demonstração. Ainda bem. Grandes demonstrações raramente explicam quem é dono da fronteira de arredondamento.
A crate do solver conta a mesma história. Expõe traços de sistemas ODE, RK4, RKF45, Euler, configuração orientada a BDF, controlo adaptativo de passo, deteção de eventos e tempo de solver determinístico. A crate de runtime é dona do ciclo de vida do FMU, dos modos de evento e de tempo contínuo, do acesso a variáveis, das derivadas de entrada, das derivadas direcionais e adjuntas, da cache de Jacobianos, dos relógios e da serialização de estado. Nada disso é útil se a camada numérica não for fiável quando se move entre hardware. O solver pode ser inteligente. O modelo pode ser elegante. Se a mesma execução precisar de três reconciliações, a elegância é sobretudo mobília.
A co-simulação é onde as pequenas mentiras se tornam caras
Um FMU já é trabalho suficiente. Vários FMUs acoplados entre si é onde os erros numéricos e operacionais se tornam sociais. Um modelo térmico alimenta um modelo de controlo, o modelo de controlo alimenta um modelo de atuador, o modelo de atuador alimenta um modelo mecânico, e todos esperam que a ordem dos passos não esteja silenciosamente a criar disparates. A co-simulação precisa de gestão de ligações, ordem de execução, troca de dados, coordenação de passos, tratamento de loops algébricos e uma forma de dizer não quando o grafo está errado.
A fonte tem fmi-orchestration para esse trabalho. Trata da co-simulação multi-FMU, ligações, deteção de ciclos, ordenação topológica, agendamento de partições, deteção e resolução de loops algébricos, histórico de valores, ordem de execução, tempo de simulação e estatísticas de orquestração. Há fmi-cc para comunicação entre FMUs acoplados e fmi-dist para execução distribuída com coordenadores, registo de nós, mensagens, pedidos de passo, respostas de passo e valores de estado. Esse é o tipo de maquinaria que as pessoas esquecem quando dizem que a integração é apenas ligar saídas a entradas. É ligação, sim. É também temporização, gestão de dependências, estado, falha e prova de que a ligação fez o que dizia.
A co-simulação também torna a determinação mais importante, não menos. Se um FMU se desvia ligeiramente e esse valor alimenta outro FMU, a discrepância pode propagar-se. Se a ordem de execução mudar entre nós, a discrepância pode esconder-se até um passo posterior. Se um backend usar um caminho matemático ligeiramente diferente, a discrepância pode parecer comportamento do modelo. É assim que as equipas acabam a depurar física com atas de reuniões. Ninguém devia ter de fazer isso, a menos que tenha sido muito mau numa vida anterior.
Os backends são escolhas de implementação, não novas verdades
A árvore de código-fonte separa os alvos de execução em crates de backend: CPU, GPU, FPGA, edge e distribuído. O backend edge foca-se em dispositivos limitados, memória limitada e baixa sobrecarga. O backend FPGA lida com aritmética de ponto fixo, transferências DMA, gestão de bitstream, execução de kernels e hardware-in-the-loop. O crate distribuído coordena vários nós. A página pública descreve caminhos de CPU SIMD, GPU, FPGA, edge e distribuído. Isso não significa que cada alvo seja igualmente maduro para cada carga de trabalho. Significa que a arquitetura trata a escolha de backend como uma preocupação de primeira linha.
O princípio de design crucial é que a implementação deve mudar onde a simulação corre, não o que a simulação significa. Um caminho de CPU pode ser o mais fácil para autoria e verificação. Um caminho de GPU pode fazer sentido para cargas de trabalho paralelas grandes. Um caminho de FPGA pode ser necessário para tempo real ou hardware-in-the-loop. Um caminho de edge pode ser necessário perto da máquina. A execução distribuída pode ser necessária para sistemas acoplados grandes. Essas são escolhas operacionais. Não devem criar uma nova identidade numérica para o modelo.
É também aqui que o código aberto importa. Em segurança, energia, robótica, dispositivos médicos, automóvel, aeroespacial, controlo industrial e gémeos digitais, as alegações de reprodutibilidade não podem viver apenas em diapositivos de fornecedores. Alguém tem de inspecionar a implementação, fixar uma versão, correr os testes, ler os casos de falha e decidir se a evidência é suficientemente boa. Uma implementação FMI de código aberto dá às equipas um melhor caminho para essa evidência. Não certifica nada magicamente. Torna o trabalho inspecionável, que é o primeiro passo útil.
A validação deve ser um portão, não um painel
A história de validação do Dweve FMI não é apenas sobre traços bonitos. O README e o site descrevem verificações de referência MPFR, equivalência entre backends, reprodução determinística, testes de conformidade, fuzzing e falhas tipadas. O código-fonte tem fmi-test, fmi-fuzz, fmi-bench, fmi-conformance, testes de propriedade, harnesses de fuzzing e serialização de estado. Essa é a direção correta. Em infraestrutura de simulação, a validação não deve ser um painel onde uma linha vermelha parece preocupante e alguém promete vigiá-la. Deve ser um portão.
O portão tem várias partes. A importação tem de analisar o arquivo FMU e o modelDescription corretamente. A validação de esquema tem de rejeitar definições de variáveis, dependências, relógios e atributos inválidos. As verificações numéricas precisam de um oráculo quando a alegação é precisão. A paridade entre backends precisa do mesmo estado em todos os alvos de execução. A reprodução precisa de estado guardado e registos de eventos para reconstruir a execução. As falhas precisam de erros tipados, não de um relatório de incompatibilidade misterioso que envia a equipa a explorar registos. Uma incompatibilidade deve bloquear um caminho de lançamento até ser compreendida ou explicitamente aceite. Isso só parece duro se a alternativa ainda não te tiver cobrado.
Onde isto importa primeiro
Os domínios óbvios são aqueles em que os erros de simulação se tornam erros físicos: automóvel, aeroespacial, controlo industrial, dispositivos médicos, energia, robótica e infraestruturas. Um modelo de travão, um controlador de bomba, um modelo de rede, uma célula robótica, uma linha de fábrica ou um controlador de AVAC não fica mais seguro porque um diapositivo diz gémeo digital. Fica mais seguro quando o modelo, as entradas, o perfil numérico, o backend, a versão e o registo de repetição são suficientemente controlados para serem investigados.
Há também uma vertente de aquisição, porque, claro, há. Se cada backend exigir uma história de validação separada, cada alteração de hardware torna-se um pequeno exercício de recertificação. Se o mesmo FMU puder ser comprovado uma vez e depois executado no alvo que se ajusta à restrição operacional, as equipas ganham liberdade sem fingir que a validação é gratuita. O sítio descreve isto como comprovar uma vez e executar em qualquer lugar. A tradução de engenharia é ligeiramente menos romântica: reduzir o número de lugares onde o mesmo modelo pode discordar de si próprio.
Isto é especialmente relevante na Europa. A soberania não é apenas onde o servidor está. É também se um caso de segurança pode ser inspecionado, repetido e movido sem implorar permissão a um fornecedor. Uma implementação aberta, aritmética determinística, repetição reproduzível e paridade de backend não resolvem a política por si só. Tornam a parte técnica menos dependente de uma caixa negra com uma equipa de vendas associada.
O que rever antes de confiar
A primeira questão de revisão é quais superfícies FMI 3.0 o seu modelo utiliza realmente. Model Exchange, Co-Simulation, Scheduled Execution, relógios, derivadas, eventos, variáveis binárias, cadeias de caracteres, matrizes e dependências não são a mesma carga de trabalho. Um FMU simples e uma simulação acoplada de múltiplos FMU exercem pressões diferentes no runtime e no orquestrador.
A segunda questão é qual perfil numérico o modelo declara e porquê. Se a resposta for o padrão que funcionou no exemplo, isso não é um design. O perfil deve corresponder ao intervalo, à resolução, à representação temporal, à tolerância e ao alvo de implantação. Deve ser suficientemente visível para que um revisor possa contestá-lo sem ler o solver inteiro.
A terceira questão é que evidência viaja com um resultado. Qual versão de origem? Qual versão de FMU? Qual modelDescription? Qual perfil Numerus? Qual backend? Quais verificações de oráculo? Qual estado de repetição? Quais testes de conformidade ou propriedade? Se essas respostas estão dispersas por uma wiki e pela memória de alguém, a simulação ainda não está pronta para ser confiável num fluxo de trabalho sério.
A lição
A lição do Dweve FMI não é que os padrões de simulação são aborrecidos. São aborrecidos exatamente da mesma forma que as pontes são aborrecidas quando se mantêm de pé. O FMI fornece o envelope de troca. O ponto fixo suportado por Numerus fornece a postura aritmética determinística. As crates de runtime e solver fazem o modelo avançar. A orquestração liga FMUs sem fingir que o tempo é trivial. Os backends movem a execução para o hardware que se ajusta ao trabalho. A validação transforma a semelhança num critério em vez de uma esperança.
É esse o trabalho. Não uma grande afirmação de que os números estão resolvidos para sempre. Não uma demonstração brilhante onde tudo corresponde porque apenas um caminho foi testado. Um sistema de simulação que conhece os seus formatos, declara o seu contrato numérico, funciona em vários backends e falha ruidosamente quando o mesmo modelo deixa de ser o mesmo modelo.
O modelo não deve desenvolver uma personalidade. Já temos suficientes dessas em reuniões.