简介《达索PLM那些事2Enovia系统架构终稿》是一份面向PLM实施顾问、系统架构师及制造业信息化人员的中文技术文档旨在系统讲解达索Enovia PLM平台的整体架构。文档从业务逻辑架构、系统安装部署架构、应用架构、技术管理架构、数据仓库架构及业界标准支持六个方面展开业务层面覆盖新产品概念、产品规划、设计开发、生产、上市、售后服务与退出市场等全生命周期环节并延伸至产品数据管理、工艺管理、配置管理和成本管理部署层面说明了应用服务器、数据库服务器、文件服务器与License服务器的职责划分应用层面具体阐述PDM、项目管理、BOM管理、流程管理、配置管理和CAD集成技术层面则介绍存储层-应用层-使用层的三层结构、TomEE中间件、数据建模、缓存及适配器技术数据仓库层面解释了多Vault的物理隔离机制标准方面强调对国际化、操作系统、数据库、中间件及浏览器的广泛兼容。资源仅1个PDF文件约993KB便于阅读。目前已有529人学习/下载适合PLM选型评估、系统规划或实施培训时参考。1. Enovia系统架构这份PDF先帮你回答三个落地问题给新同事讲 Enovia 系统架构是 PLM 项目里最吃力不讨好的事。功能清单背得下来可一到“文件服务器为什么得单独一台”“Vault 之间到底隔没隔离”多半卡住。这份 PDF 把 Enovia 从业务逻辑、部署、应用、技术管理、数据仓库、标准支持六个维度拆了一遍不堆功能点而是讲清楚整套系统在业务、服务、数据三个层面怎么组织。适合准备架构评审的新手实施顾问也适合要评估扩容或灾备的老手。读完至少能回答三个问题Enovia 装在哪几个节点、数据存在哪里、License 认证怎么走。2. 业务逻辑架构从立项到退市先给PLM主线做模块落点作者把业务逻辑放在第一个位置这个排序是对的。我在实施里见过太多项目一上来就谈服务器、谈数据库业务梳理不清最后所有配置都要返工。业务逻辑架构回答的是“系统到底要管哪些事”后面所有部署决策——几个节点、什么存储、怎么备份——都是被它推导出来的。Enovia 管的是产品全生命周期这句话不难理解难的是把它落到模块和交付物上。2.1 七个环节一条主线先画阶段门再找交付物原文把全生命周期划成新产品概念提出、产品规划、设计开发、生产、上市、售后服务、退出市场七个环节。它们不是并列的是串在一条时间轴上的。我在做蓝图设计时习惯先画一张阶段门表把每个环节的关键活动、平台落点和关键交付物对齐这样业务部门能直观看到自己在哪个环节干活、要交什么数据。环节关键活动平台常用落点关键交付物概念提出可行性分析、立项申请项目管理、文档管理立项书、需求文档产品规划计划编制、资源分配项目管理、任务管理项目计划、任务分解设计开发结构设计、电路设计、仿真PDM、CAD集成、仿真管理CAD模型、EBOM、仿真报告生产准备工艺路线规划、工步划分工艺管理、Delmia工艺BOM、作业指导书上市与售后工程变更、问题跟踪变更管理、问题管理变更单、问题记录退出市场数据归档与处置归档管理、Vault归档包、处置记录这张表的价值在于每个阶段的交付物最终都要回落到某个数据对象上——Item、Document、Form。这就是 PDM 的入料口。梳理主线时先找交付物再找对象最后定签审流程顺序不能反。我见过反着来的项目先画了一堆流程节点上没有数据流程就是空转业务部门根本不点。2.2 研发环节四个工具角色各自的数据怎么进Enovia原文明确列出了研发阶段的几个工具角色它们不是平行关系而是围绕同一个产品结构在喂数据。MCADCATIA、SolidWorks 等做结构设计产出三维模型和设计结构V6 里与 CATIA 的集成本身是原生的SolidWorks 走通用集成接口ECAD 做电路和 PCB 设计产出的是电气对象和机械对象都挂在产品结构下只是对象类型不同。这里要特别注意集成方式不同文件服务器上存储的数据格式和后续签审路径也不同我一般会在蓝图阶段就把每个 CAD 工具的集成方式确认下来避免上线后改接口。Delmia 是工艺和工厂布局的落点它把工序、工步和产线行为串起来对应的是加工生产维度里的控制逻辑。Simulia 做仿真分析仿真模型和结果文件往往很大很多企业第一次磁盘空间爆掉不是 CAD 图而是仿真结果。这四个工具和 Enovia 的互动本质都是“数据进出”的问题这也是后面数据库服务器和文件服务器存在的业务理由。2.3 四个管理维度PDM、BOM、工艺、知识各管什么原文从四个维度做了细化我在实施中会把它们拆成四个数据边界。项目过程管理维度本质是把工作分解成可控颗粒度并为数据管理提供交付物这里的关键是任务和交付物要绑定否则任务管理就是台账。有效数据管理维度PDM 管的是“结果数据”不是工程师本地那些过程草稿签审流程决定一份数据是否有效这是单一数据源的前提。BOM 完整性维度最容易混淆。DBOM 是从 CAD 装配结构直接映射出来的设计视图体现产品“设计成这样”EBOM 是经过工艺调整后的工程视图增加工艺件、拆分自制和外购体现“实际怎么做出来”。实施时如果只建一套 BOM后面工艺变更和生产准备一定会翻车。加工生产维度通过工艺路线把工序细分为工步每个工步对应具体加工环节最后落到整个工厂生产线的工艺控制行为这套数据由工艺管理模块承载。2.4 与SAP等ERP集成边界画在哪里原文提到通过和 SAP 等 ERP 集成来支撑全生命周期管理这在实际项目里永远是个热门话题。集成先画边界物料主数据一般在 ERP产品结构在 PLM工程变更在 PLM 发起、ERP 接收结果避免两边同时写同一份数据。常见做法是用接口表或 WebService 做中间同步Enovia 发布设计 BOM 和 EBOM 给 ERPERP 回传成本、库存和供应商状态方向明确测试用例也容易定。集成层放在应用层的适配器里做不影响存储层的数据结构这一点在部署架构里要提前留出接口和网络白名单。3. 部署架构与服务器规划A/D/F/L四类服务这样分工原文把部署拆成应用服务器、数据库服务器、文件服务器和 License 服务器四类简称 A/D/F/L这是很实用的拆法。四类服务可以合装也可以分散开判断标准就三条备份窗口、IO 竞争、安全边界。业务逻辑决定了数据流向部署架构决定这些数据在物理上落在哪我在给客户做规划时基本都是按这个框架去推导节点数量和配置。3.1 四类服务的职责拆解各管什么硬件倾向哪里很多新手容易把应用服务器和数据库服务器当成一回事实际它们的分工非常明确。应用服务器跑业务逻辑和客户端通讯是无状态的扩并发优先加应用节点数据库服务器存业务对象和 Vault 元数据是有状态的核心硬件预算要重点投内存和 SSD文件服务器存实体文件而且原文特别强调是“加密的方式保存”这是为了防止文件被从存储层直接拷走License 服务器做许可证认证客户端没有它授权根本无法使用系统。服务软件职责硬件倾向A 应用服务器应用服务 TomEE客户端通讯、业务逻辑、缓存CPU 与内存D 数据库服务器Oracle / DB2业务对象、Vault 元数据、权限高频 IO、大内存F 文件服务器Enovia 文件服务加密存储实体文件大容量磁盘L License 服务器License 管理服务许可证认证低配但要求高可用合装时最容易出问题的是 D 和 F 抢 IO 和磁盘带宽所以即便预算受限我一般也会建议把这两者分开。加密存储这个点被很多人忽略它意味着你在文件服务器上看到的文件名和内容都不是原始形态直接拿文件出去是没有用的这本身就是一层数据防泄漏手段。3.2 一套起步配置200并发以内的节点规划中小型制造企业两百人以内并发使用不需要一上来就上集群但节点要有合理边界。我给出一个常见起步方案实际项目按并发数和数据量调。应用服务器两台做负载均衡无状态所以扩容容易数据库一台大内存 SSD 服务器文件服务器按仿真数据量预留空间License 用独立小虚拟机。节点建议配置备注应用服务器 ×216C / 64G千兆内网无状态可水平扩展数据库服务器 ×116C / 128GSSDOracle 19c单实例文件服务器 ×18C / 32G大容量存储加密文件按仿真数据预留License 服务器 ×14C / 8G主机名固定不随意迁移这套方案的要点是数据库是 IO 瓶颈预算优先给 SSD 和内存文件服务器要留出备份带宽建议独立内网段别让大文件传输占用业务链路应用服务器可以随时加节点因为它的状态都回落到数据库和文件服务器上。3.3 数据存在哪用MQL确认Vault与数据库实例的对应Vault 是 Enovia 的数据存储容器排查“数据到底在哪个库”时我一般会先登录应用服务器进入 MQL 管理命令行执行下面两条命令mql list vault ; mql print vault eServiceProduction ;第一条命令列出当前环境里配置的所有 Vault 名称第二条查看某个 Vault 的详细属性包括它的存储策略、关联程序等。要确认这个 Vault 落在哪个 Oracle 实例最直接的方式是到数据库侧查当前实例名再做比对。这里要记住Vault 的隔离级别取决于数据库实例不是 Vault 本身。3.4 License认证路径客户端到License服务器的调用链License 认证不是客户端直连 License 服务器而是先连应用服务器再由应用服务器到 License 服务器取认证。整个链路是客户端 → 应用服务器 → License 服务器取到授权后应用服务器才会放行会话。常见误区是认为 License 只认账号实际部署中 License 服务器绑定主机信息换主机名或换 MAC 就要重新申请授权所以 License 节点最好用独立虚拟机主机名固定下来不再动。出现“并发显示占满但实际没人用”的情况多数是残留会话没清理重启 License 服务前先把会话状态看一遍。4. 技术管理架构与数据仓库三层结构加Vault隔离原文把技术管理架构划成存储层、应用层和最终使用层这个分层和部署架构是对应的。存储层解决“数据在哪”应用层解决“服务怎么对外”使用层解决“用户怎么访问”。我在做技术方案时会把三层画成一张职责表再逐层和 A/D/F/L 服务对应起来这样评审时别人一问就知道边界。4.1 三层职责存储、应用、使用各自承载什么存储层里实体文件在文件服务器数据对象和业务模型在数据库服务器两者是分开的。应用层通过 TomEE 提供应用服务同时承担数据建模、缓存和适配器三类任务。使用层有两类用户入口一类是浏览器做结构化数据管理另一类是富客户端做三维模型的构建和编辑。这两类入口访问的协议和端口不一样网络策略要分别放行。层承载说明存储层文件服务器 数据库服务器实体文件加密存对象与模型在数据库应用层TomEE、数据建模、缓存、适配器对外提供应用服务使用层浏览器、富客户端Web 管数据富客户端做 3D 编辑存储层的两个组成部分必须同时备份且时间点对齐这个我在后面避坑章节还会专门讲。应用层是整个系统里最容易被低估的数据建模决定对象关系缓存决定读写速度适配器决定和其他系统集成能不能通。4.2 应用层三个关键件TomEE、缓存与适配器应用层不是简单跑个 Web 服务它同时承担三件事。数据建模用于构建各个对象之间的数据关系对象类型、属性、关系都在这一层定义常见做法是通过业务模型设计器或者脚本去改模型模型变更后要重新部署相关组件。缓存用于加快数据存储和读写速度但缓存也是实施里最常踩坑的地方——权限改了、模型改了前端看到的是旧状态我一般在变更后会主动刷新应用缓存再验收。适配器用于实现与其他业务系统的关联应用SAP、MES、OA 都走这一层。TomEE 是 V6 近几个版本常用的中间件它承接了浏览器和富客户端的请求所以应用层出问题时的排查入口是 TomEE 日志。注意 TomEE 版本和 Enovia 补丁必须对齐这个细节放到避坑章节展开。4.3 数据仓库Vault物理隔离的价值与代价原文对 Vault 的描述很关键每个数据仓库对应数据库不同的实例Oracle 实例之间物理隔绝不能相互访问。这是 Vault 隔离的本质。多 Vault 管理最大的价值是做保密级别和产品线的数据隔离比如军品和民品分开、研发和售后分开各自独立实例即便一个实例故障另一个不受影响。代价也很现实每个 Vault 都要单独的数据库实例备份量翻倍维护成本增加DBA 要管理多个实例。我在项目里会先问客户你们要的是合规要求下的物理隔离还是只是业务上“账能分开”如果是后者同一个实例里做逻辑分区就够了别把成本堆在不必要的实例上。4.4 业界标准支持MatrixOne三十年沉淀带来的兼容性原文提到 MatrixOne 系统自 1993 年发布历经市场三十多年在国际化、操作系统、开发语言、数据库、中间件、数据安全、浏览器等层面兼容性都很好Enovia 作为升级产品继承了这些。这一点在企业选型时非常重要过信息安全评审和架构评审时一个支持国际主流标准的系统比封闭系统好过得多。我参与的项目里客户问得最多的是浏览器版本兼容和中间件是否受控这些问题的答案基本都能从标准支持范围里找到依据。5. 避坑指南Enovia架构落地中的五个典型问题架构图画得再漂亮落地时踩坑的还是那几个老地方。下面五条是我在多个项目里反复遇到过的每条按现象、原因、解决写清楚供你规划时直接对应。5.1 文件服务器与数据库备份不在同一时间点恢复后文件变孤儿现象系统故障后做恢复数据库能正常启动但打开 CAD 附件报“文件不存在”或者图标还在、内容打不开。原因数据库和文件服务器各自备份数据库恢复到 T0 时间点文件服务器却恢复到了 T02 小时。数据库里的对象索引指向了文件服务器上不存在或不完整的文件两边对不上。解决把数据库和文件服务器纳入同一个备份策略停应用做一致性备份或者用存储快照同一时刻抓取。恢复完成后第一件事是抽查对象确认文件和数据匹配再放业务进入。我从那以后每次灾备演练都强制走一遍这个验证流程不再轻信“两边都备份了”。5.2 在同一个Oracle实例里建多个Vault误当物理隔离用现象两个业务部门说“我们是两个 Vault物理隔离”实际跑在同一个 Oracle 实例上。一个部门做批量操作把 IO 吃满另一个部门跟着卡顿。原因把 Vault 等同于隔离忽略了原文反复强调的“每个 Vault 对应数据库不同实例”。同一个实例里的多个 Vault 只是逻辑上分开物理上共享计算资源和 IO 通道。解决合规要求物理隔离的场所一个 Vault 一个实例只是业务上要“账能分开”的场景用逻辑分区可以接受但别对外宣称物理隔离。规划前先和客户确认隔离等级避免后期整改。5.3 TomEE版本与V6补丁不对齐应用服务起不来现象应用服务器启动时报 ClassNotFound或者页面服务能起来但某些模块一点就报错。原因Enovia V6 不同小版本对中间件版本有明确要求。安装时随手拿了一个 TomEE 版本和当前补丁不匹配类加载阶段就失败。解决安装前先核对补丁说明里的中间件版本清单确认 TomEE 的准确版本号。升级时先把原中间件目录完整备份再按版本对齐回滚时直接替换目录即可这个后悔药是必须留的。5.4 License服务器单点故障重启后授权数异常现象License 服务器宕机全员无法签入系统。重启后 License 池明明有空闲却提示“数量不足”。原因License 服务依赖主机信息主机名或 MAC 变了授权就失效。另外服务重启后会话没有完全释放残留会话占着并发名额新用户签入时被误判为超量。解决License 节点独立部署主机名和 MAC 固定不随迁移变动。重启后先检查会话残留清理干净再开放签入。给 License 服务器做冗余方案时要确认原厂支持的主备模式别自己乱搭。5.5 Web端能用但富客户端连不上建模功能全部空白现象浏览器打开数据管理页面正常列表和流程都能用但富客户端一直连不上服务三维模型区空白。原因富客户端和 Web 端走的协议、端口不一致防火墙只放行了 HTTPS 的 443 端口富客户端使用的专用端口没放行。解决核对该版本安装文档里的完整端口清单把富客户端所需端口单独开通。这类端口往往要通过安全评审提前提交申请别等上线当天才报否则交付时间就卡在网络审批上。6. 部署后体检从License池到Vault的一轮快速验证新环境部署完别急着让业务部门录数据先花十分钟做一轮体检。我习惯把常用检查项写成一个脚本按实际环境替换主机名和端口就能跑#!/bin/bash # Enovia 部署后快速体检脚本 # 用法: ./check_env.sh APP_HOST10.0.1.10 LIC_HOST10.0.1.11 LIC_PORT28000 echo 1. 应用服务进程 ssh $APP_HOST ps -ef | grep -E java.*(tom|tomee) | grep -v grep | wc -l echo 2. License 池状态 lmstat -a -c $LIC_PORT$LIC_HOST 2/dev/null | head -30 echo 3. 数据库实例状态 sqlplus -S system/password$APP_HOST:1521/ENOVIA EOF select instance_name, status from v\$instance; exit; EOF echo 4. 文件服务器挂载与空间 ssh $APP_HOST df -h | grep -E enovia|vault echo 5. Vault 清单 ssh $APP_HOST echo list vault ; | mql第一项看应用进程数数值大于 0 只代表进程存活还要去 TomEE 日志确认没有启动报错。第二项用 lmstat 看 License 池-c 28000host是 FlexNet 常见端口写法实际端口以安装文档为准。第三项连数据库实例ENOVIA是服务名按实际配置改这里主要确认实例状态是 OPEN。第四项看挂载点空间使用率超过 80% 就要提前规划扩容。第五项用 MQL 列出 Vault 清单确认和规划一致再配合print vault看单个 Vault 详情。这套体检的顺序是有讲究的先确认应用活着再确认授权够然后确认数据层和存储层健康最后确认仓库结构没跑偏。我养成这个习惯是吃了两次亏换来的一次同事说“环境好了”结果 License 服务没启另一次 Vault 确实在但文件服务器挂载点满了也没人发现。从那以后我在每个新环境部署完第一件事不是录数据而是把这五步轮着跑一遍确认进程、License、实例、挂载、Vault 全部对齐才让业务部门进场。版本升级和灾备演练之后这个顺序也适合再做一轮希望帮到你。本文还有配套的精品资源点击获取