Recomendações a outras pessoas considerando Centro:
Esteja ciente das atualizações em cascata em montagens muito grandes com múltiplas submontagens. Se os projetistas estiverem usando a funcionalidade de check-out/check-in e fazendo check-in de múltiplos componentes de camada inferior, cada submontagem na árvore iniciará uma atualização em cascata para miniaturas, arquivos SpinfireWeb e Spinfire Ultimate. Dependendo da complexidade da montagem, os arquivos Spinfire Ultimate podem se tornar muito grandes quanto mais alto você subir na árvore de navegação. Você pode consumir uma grande quantidade de espaço em disco sem nem perceber. Além disso, as atualizações em cascata utilizam o Pipeline do Sistema, que atualmente está codificado para executar apenas um trabalho simultâneo por vez. Montagens grandes podem sobrecarregar os Pipelines do Sistema. Decidimos desativar todas as conversões Spinfire Ultimate (ACT3D) e criar apenas miniaturas e conversões Spinfire Web.
Também observe: a opção "Gerar..." no menu de recursos definirá automaticamente as conversões para cascata sempre que houver uma alteração. Por exemplo, se você quiser criar uma conversão STEP, precisa selecionar "Gerar..." e marcar a caixa de conversão STEP. A partir desse ponto, essa conversão será sempre atualizada com uma nova versão sempre que o arquivo nativo mudar. Essas versões podem se acumular e consumir espaço em disco. Se estiver criando uma conversão STEP única e não precisar que essa conversão STEP seja atualizada toda vez que houver uma alteração na montagem, certifique-se de voltar ao menu "Gerar..." e desmarcar a conversão STEP.
Também certifique-se de que todas as montagens que você decidir enviar para o pipeline estejam 100% vinculadas à montagem de nível superior. Existem muitas maneiras de fazer isso. No Catia, você pode colocar tudo no modo de design e usar o gerenciamento de salvamento para vincular todos os componentes corretamente. Você também tem a opção de usar o comando "Enviar para..." que salvará o produto de nível superior e os componentes em um diretório diferente, como um Diretório de Observação do Centro. No NX, você pode usar a ferramenta de clonagem para fazer o mesmo. Se você tiver componentes salvos em diretórios diferentes que o Centro não pode acessar, pode acabar com uma montagem de nível superior com links quebrados para seus componentes.
A maior lição que aprendemos: compartilhar componentes com o mesmo nome exato entre dois OEMs diferentes pode ser desastroso. Por exemplo, JLR e Ford frequentemente usam os mesmos nomes de peças no Teamcenter, já que a JLR foi uma vez propriedade da Ford. A beleza original do Centro era a capacidade de usar a função "onde usado" para ver todas as montagens que usavam um componente específico. Isso é perfeito para VA/VE, oportunidades de redução de custos e muitos outros benefícios. O problema subjacente a isso são as idiossincrasias com o software CAD nativo e as versões que os OEMs usam. Se dois OEMs diferentes usarem a mesma peça, mas versões diferentes de CAD, há uma chance de que um projetista usando um nível mais alto de CAD nativo sobrescreva o nível mais baixo de CAD. O outro projetista do OEM não poderá abrir esse arquivo para fazer alterações. Tivemos que resolver esse problema adicionando prefixos específicos de OEM em nossos pipelines. Perdemos a funcionalidade "onde usado", mas mantemos nosso CAD nativo consistente com a versão do software CAD nativo do OEM. Algumas funcionalidades estão disponíveis para nós, no entanto: a guia Duplicatas. Isso então nos mostrará peças duplicadas e o prefixo CatalogID nos mostra o OEM.
Por último, cuidado com implementações globais que usam o modelo de arquitetura distribuída onde há um banco de dados Arango vinculado a múltiplos Gerentes de Pipeline/Hosts de Pipeline. Há um problema de latência que impede o uso ao fazer login em um Host de Pipeline europeu que acessa um banco de dados Arango norte-americano. Essa configuração é insuportável de usar na Europa a ponto de os usuários finais não a utilizarem devido ao atraso. Estamos considerando dividir nossos bancos de dados Arango para que haja um para todas as instalações na Europa e outro para as instalações na América do Norte. Essa opção quebra qualquer aspecto de busca e compartilhamento global entre continentes, mas melhorará a adoção pelos usuários.
Nota adicional de atualização: a RAM do sistema parece ser o maior gargalo e o aspecto mais crítico do servidor Host de Pipeline. Há um equilíbrio entre a quantidade de núcleos e a RAM disponível. Fizemos alguns testes que saturaram os núcleos da CPU executando múltiplos pipelines com seis trabalhos simultâneos por pipeline. O que descobrimos é que, uma vez que a RAM disponível é saturada, o sistema começará a gravar dados no arquivo de troca. Quando isso acontece, quando o Host de Pipeline está acessando montagens muito grandes para processar conversões SpinfireWeb, ACT3D e miniaturas, elas provavelmente expirarão. Devido ao volume de pipelines que temos sempre em execução, estamos considerando um servidor independente com 500GB de RAM e 32 núcleos. Nossa solução temporária agora é limitar os trabalhos simultâneos por pipeline a três, bem como limitar quantos pipelines executamos. Continuamos a monitorar os recursos do sistema e garantir que nosso uso de RAM nunca exceda 75% de utilização. Lições aprendidas: evite saturar a RAM do sistema a ponto de o Host de Pipeline mover enormes quantidades de dados para o arquivo de troca. Análise coletada por e hospedada no G2.com.
Que problemas é Centro E como isso está te beneficiando?
Compartilhamento global de CAD, biblioteca de modelos de recursos, biblioteca de fixadores, fluxo de trabalho de design Análise coletada por e hospedada no G2.com.
