语义STEP技术/SST：工业产品数据管理与互操作的新模式

一、引言：当“交换”不再等于“理解”

       在制造业的数字化转型中，一个基础性问题是：数据如何跨系统保值、标准如何真正落地——答案藏在产品数据语义之中。

       在工程领域，数据交换的故事已经讲了几十年。一个机械工程师用SolidWorks设计了一个齿轮箱，导出为STEP文件，发给同事，同事在CATIA中打开——几何形状完整无损，一切看起来都很美好。但这个故事有一个隐含的假设：交换数据就等于理解数据。实际上，这两个系统之间传递的，不过是一堆几何坐标、拓扑关系和属性字符串。CATIA知道“这是一个圆柱面”，但它不知道“这个圆柱面是轴承座孔的基准面”；它知道“这个孔的直径是20mm”，但它不知道“这个公差等级是H7，是为了与某型号滚动轴承配合”。几何信息过去了，设计意图留在了原地。

       这正是今天工业数据互通面临的核心困境。我们拥有比以往任何时候都更强大的计算能力、更丰富的传感器数据、更复杂的数字孪生模型，但不同系统之间仍然像说着不同方言的旅人——词汇表或许能勉强对应，但背后的概念框架、分类逻辑、约束规则却各成体系。ERP里的“零件”是一个财务成本对象，PDM里的“零件”是一组几何和属性的集合，MES里的“零件”是一道工序流转的载体。同一个符号“零件”，在三套系统中绑定了三套不同的概念框架，指向现实中同一个物体，却在数据层面无法被识别为同一个东西。

       这种困境的本质，可以用“三层世界”模型来理解。第一层是现实层——真实存在的机床、产品、工艺过程；第二层是本体层——人类为理解现实而构建的概念体系，它规定了这个领域里“有什么”“怎么分”“怎么关联”；第三层是符号层——数据库里的编码、文件里的字符串、API里的字段名。符号要获得确定的意义，必须经过“锚定”过程：绑定到第二层本体层的某个具体位置，才能稳定地指向第一层的某个现实对象。大多数企业的问题不在于缺乏符号，也不在于缺乏现实，而在于不同系统使用了不同的本体层。数据在符号层流动，却因为缺乏共享的本体层，永远无法真正抵达对方。

       语义STEP技术（Semantic STEP Technology，简称SST）正是在这一背景下应运而生。它不是又一个文件格式，也不是又一个转换器，而是一套将ISO 10303（STEP）标准的产品数据模型与W3C语义网技术深度融合的系统性解决方案。SST的目标，是在保留STEP等一系列国际标准数十年积累的工业数据建模成果的同时，赋予这些数据以机器可理解的语义，从而实现真正意义上的跨系统语义互操作。

       本文将从行业背景、历史脉络、技术原理、功能特色、应用场景和前景展望六个维度，对SST技术进行系统性的梳理和阐述。文章力求做到既有“骨头”（结论和框架）又有“肉”（来龙去脉和具体疏理），使其不仅可作为技术决策的参考，也可作为扩展工业设计、工程数据、生产管理类软件相关知识的参考资料。

二、从IGES到STEP：产品数据交换的四十年求索

       2.1 1980年代：伴随计算机设计的困扰与IGES的诞生

       1970年代末到1980年代末，CAD软件如雨后春笋般涌现。每个厂商都有自己的专有文件格式：AutoCAD有DWG（继承Mike Riddle的Interact CAD；附带 ASCII 交换格式 .dxf）。Unigraphics（早期叫 Uni-Graphics）有.prt。早期Dassault Systèmes/达索的CATIA依附IBM平台与CADAM生态，数据容器随版本/平台变化，早期主机版CATIA的数据组织称为CDF数据集，但CDF与.model的精确版本对应关系不稳；到了CATIA V4时期，.model/.exp等文件形式更为常见；CATIA V5则更多对应.CATPart、.CATProduct、.cgr。Pro/ENGINEER（现Creo Parametric）有.prt零件、.asm装配文件、还有.drw工程图。如此这般，令人眼花缭乱的格式，使得工程企业一旦选定了某家CAD系统，就意味着整个设计流程被锁定在这个生态中。当需要与使用其他系统的供应商或合作伙伴交换数据时，唯一的办法是手动重绘——这在今天听起来不可思议，会使人直接崩溃，但在当时是常态。

       1980年，美国国家标准局（NBS/ National Bureau of Standards Publication，后来的美国国家标准与技术研究院，NIST/National Institute of Standards and Technology）发布了IGES（Initial Graphics Exchange Specification，初始图形交换规范），这是第一个被正式标准化的中性文件格式。IGES的初衷是解决2D/3D线框和曲面模型在不同系统之间的交换问题。它采用一种类似“图纸语言”的思路，将几何元素（点、线、圆弧、曲面）以文本形式描述，让不同系统都能读写。

       IGES确实解决了一部分问题，但它的局限很快暴露出来。首先，IGES本质上是一种“图形交换”格式，而非“产品数据交换”格式。它能描述一个零件长什么样，却不能描述这个零件是什么材料、有什么功能、如何装配、满足什么标准。其次，IGES的实体类型（Entity Type）体系相对简单，面对日益复杂的实体造型（Solid Modeling）和边界表示（B-rep）技术时显得力不从心。到1980年代中期，工程师们已经意识到：我们需要的不只是交换几何形状，而是交换完整的产品信息。

       2.2 1984-1994：STEP标准的十年孕育

       1984年，在IGES经验的基础上，国际标准化组织（ISO）的技术委员会TC 184（工业自动化系统与集成）启动了一项雄心勃勃的计划：制定一个能够完整描述产品全生命周期信息的国际标准。这就是ISO10303，其非正式名称为STEP（Standard for the Exchange of Product model data，产品模型数据交换标准）。

       STEP的设计哲学与IGES有本质不同。IGES是一种“文件格式”思维：规定好文件里每一行写什么、每个字段什么意思，两个系统按这个格式读写即可。STEP则是一种“信息建模”思维：首先要用严格的形式化语言定义“产品信息是什么”，然后才讨论“如何编码这些信息”。这种分层设计的思想，使STEP具备了前所未有的扩展性和精确性。

       STEP标准体系极为庞大，由数十个部分组成，核心架构可分为三个层次：

       ●应用协议层（Application Protocol, AP）：面向具体行业场景的数据规范。例如AP 203针对机械零件和装配体的配置控制三维设计，AP 214针对汽车机械设计核心数据，AP 239针对产品全生命周期支持。每个AP定义了该场景下需要交换哪些信息、信息的结构和约束。

       ●集成资源层（Integrated Resources, IR）：提供跨AP共享的通用数据模型。例如Part 42定义了几何与拓扑表示，Part 41定义了产品描述和支持，Part 43定义了表达结构。IR是AP的“建筑材料库”。

       ●描述方法层：即EXPRESS语言（ISO 10303-11），这是STEP的核心创新之一。EXPRESS是一种专门为产品数据建模设计的形式化信息建模语言，它不仅能定义实体（Entity）和属性（Attribute），还能定义复杂的约束规则、继承关系、聚合类型和函数。与当时流行的图形化建模方法，如IDEF1X 数据建模方法（ICAM DEFinition 1X ，其中ICAM 即Integrated Computer-Aided Manufacturing-美国空军集成计算机辅助制造项目），如NIAM（Nijssen’s Information Analysis Method，尼森信息分析方法）相比，EXPRESS 的优势在于其强大的约束表达能力和机器可处理性。

       EXPRESS的诞生本身也有一段有趣的历史。它的雏形是1980年代初美国空军资助的PDDI（Product Definition Data Interface）项目中开发的DSL（Data Specification Language）。NBS的PDES（Product Data Exchange Specification）项目组在审查了NIAM和IDEF1X后认为，这些图形化方法缺乏足够的约束表达能力，于是开始扩展DSL，最终形成了EXPRESS。1989年，EXPRESS成为ISO草案；1994年，ISO 10303-11:1994正式发布。

       STEP的第一版于1994年发布，此后经历了2002年和2016年的修订。如今，STEP已成为航空航天、汽车、造船、电子等行业的数据交换事实标准。一个STEP文件（通常以.step或.stp为扩展名）可以精确地保存一个3D模型的几何、拓扑、材料、装配关系甚至部分PMI（Product and Manufacturing Information）信息，被誉为“3D模型的PDF”。

       2.3 STEP的成就与局限

       STEP的历史成就毋庸置疑。它成功地将产品数据交换从“图形层面”提升到了“信息层面”，使不同CAD / CAE / CAM / PDM系统之间能够交换远比几何更丰富的信息。AP 203和AP 214的广泛实施，使全球制造业的协作效率得到了质的提升。

       然而，STEP从诞生之初就带有一个内在的结构性张力：它既要追求精确性（用EXPRESS的严格约束保证数据的正确性），又要追求通用性（覆盖不同行业、不同生命周期阶段的需求）。这种张力导致了两个深层问题：

       第一，语义封闭性。EXPRESS是一种优秀的信息建模语言，但它定义的语义是“自包含”的。一个EXPRESS模式（Schema）定义了实体、属性、规则和约束，但这些定义的意义依赖于阅读模式文本的人。机器可以验证一个Part 21文件是否符合EXPRESS模式的语法和约束，但机器并不“理解”这些实体在真实世界中的含义。例如，EXPRESS可以定义一个名为“product”的实体，它有“id”和“name”属性，但机器不知道“product”在工业语境中指的是“产品”而非“乘积”。这种语义封闭性，使得STEP数据在不同领域之间的“理解”仍然需要人工翻译。

       第二，互操作成本高昂。每个AP都是一个庞大的EXPRESS模式，实施一个AP需要开发复杂的翻译器（Preprocessor和Postprocessor）。AP之间的数据映射也并非总是直接的——AP 203中的“产品”与AP 214中的“产品”在概念上相似，但在EXPRESS模式中的定义可能略有不同，这种差异需要精心设计的映射规则来处理。对于中小企业而言，全面实施STEP的成本仍然很高。截至 2024 年 10 月，SC4 已发布814项ISO标准、另有31项在研——体系的体量本身已成为实施负担的注脚。

       更为根本的是，STEP诞生于1980-1990年代，那时的计算环境是单机或局域网，互联网尚未普及，语义网（Semantic Web）的概念还未诞生。STEP的设计假设是：数据交换发生在两个已知的、有明确契约的系统之间。而今天，我们面对的是一个高度网络化、动态化、分布式的数据环境，数据需要在云端、边缘端、不同组织之间实时流动和融合。STEP的“文件交换”范式，在这种新环境中显得笨重而低效。

       2.4 四十年后的复盘：1984年目标清单的达成度

       四十多年后，在今天的数字化时代，再回顾1984年7月在美国盖瑟斯堡ISO TC184会议。复盘SC4达成的决议2中确立的ISO 10303/STEP灵活性、效率、内容与格式分离、最小可能数据集等几项设计目标，客观评估其现状，结果是这样的：

       ●"捕获完整无缺损的计算机化产品模型，贯穿产品全生命周期"——"没有真正达成，标准中存在大量相互冲突的内容"；

       ●"数据处理、通信与存储的效率"——"实现了，但以今天看来无关紧要的方式"；

       ●"数据内容与物理格式的分离"——"没有实现"；

       ●"最小可能的数据元素集合"——"恰恰相反，STEP强迫系统生成大量无用数据"；

       ●"与现有相关标准的兼容性"——"只兼容了老旧的VDA-FS和IGES，且已不再相关"。

       它揭示的问题可归纳为三点：

       ●多模型分层（AIM/MIM、ARM、域模型）造成的复杂性膨胀；

       ●严格的向上兼容教条对新架构改进的封锁；

       ●以及缺失的统一根基概念——STEP定义了数百个实体，却没有一个清晰的顶层本体来约束它们的重叠与冲突。

       2025年10月15日，国际标准日的次日，巴黎，在法国AFNeT协会主办的EWIS Day上， Lothar Klein首次公开了SST目标清单。它不是对STEP的否定，而是对ISO TC 184 SC4在1984年写下、却未兑现的那张目标清单的第二次作答：

       ●用RDF/OWL 2改善计算机可解释表示的语义；以Turtle等RDF文件格式实现中性交换；

       ●以SST Repository支撑数据库共享与云端发布；

       ●覆盖从需求、设计、配置、制造到维护、报废的全生命周期阶段；

       ●完整保存数据及其演变历史的修订档案。

       2.5 ISO 15926：过程工业的语义化尝试

       在STEP发展的同时，另一个重要的国际标准也在平行演进：ISO15926—“工业自动化系统与集成—过程工厂（包括石油和天然气生产设施）全生命周期数据集成”（ Industrial automation systems and integration — Integration of life-cycle data for process plants including oil and gas production facilities）。

       ISO 15926的起源与石油天然气行业密切相关。1990年代，欧洲过程工业界意识到，工厂的设计、建造、运营、维护涉及海量异构数据，需要一个比STEP更灵活、更语义化的集成框架。1990年代中后期，EPISTLE（European Process Industry STEP Technical Liaison Executive）和POSC Caesar（Petrotechnical Open Software Corporation与挪威Caesar海上项目的联合组织）开始合作，最终形成了ISO 15926标准族。

       ISO 15926与STEP的关键区别在于：它从一开始就采用了本体（Ontology）的思维方式。ISO 15926-2:2003定义了一个上层本体（Upper Ontology），使用面向对象和语义网的思想来描述过程工业中的实体、关系和活动。更重要的是，ISO 15926明确采用了W3C的OWL（Web Ontology Language）作为其本体表示语言之一（ISO/TS 15926-12:2018定义了用OWL表示的生命周期集成本体）。

       ISO 15926的愿景非常宏大：建立一个覆盖过程工厂全生命周期的统一信息模型，使设计数据、设备数据、运营数据、维护数据能够在统一的语义框架下被理解和集成。然而，这一愿景的实现也面临挑战：ISO 15926的数据模型极为抽象和通用，其实施需要大量的领域专用模板（Template）和参考数据（Reference Data Library, RDL），这增加了实施的复杂性。此外，ISO 15926主要面向过程工业（化工、石油、天然气），其数据模型与STEP面向离散制造业（机械、汽车、航空）的模型在风格和侧重点上有显著差异。

       尽管如此，ISO 15926的实践为工业数据语义化提供了宝贵的经验：它证明了OWL等语义网技术可以用于表达复杂的工业本体，也证明了“通用本体+领域模板”的分层架构是可行的。这些经验，后来都融入了SST的设计思想中。

三、语义网的兴起与工业数据的“语义鸿沟”

       3.1 从万维网到语义网：W3C的愿景

       1990年代末，万维网（World Wide Web）已经改变了人类获取信息的方式，但万维网上的信息本质上是为人眼设计的。一个网页对浏览器来说，不过是一堆HTML标签和文本；浏览器知道“这是一段文字”“那是一张图片”，但它不知道“这段文字描述的是某种材料的抗拉强度”“那张图片展示的是某个零件的装配关系”。换言之，网页有语法（HTML标签），但缺乏语义（内容的含义）。

       1998年，万维网的发明者Tim Berners-Lee爵士提出了“语义网”（Semantic Web）的愿景：让网络上的信息不仅可被人类阅读，还可被机器理解和处理。这一愿景的核心，是建立一套标准的技术栈，使数据能够携带明确的语义，从而支持自动推理、知识发现和跨系统互操作。

       W3C（World Wide Web Consortium，万维网联盟）随后推出了一系列关键技术标准：

       ●RDF（Resource Description Framework，资源描述框架）：1999年成为W3C推荐标准。RDF采用“三元组”（Subject-Predicate-Object即主语/subject、谓词/predicate和宾语/object，以描述具体的事物及关系）的基本形式来表达陈述，例如“零件A—材料—不锈钢”。RDF的简洁性和灵活性，使其成为语义网数据表示的基础。

       ●RDFS（RDF Schema）：在RDF基础上增加了类Class）、属性（Property）、子类（subClassOf）等概念，支持简单的词汇表定义和层次结构，用于构建本体与知识图谱的基本结构。

       ●OWL（Web Ontology Language）：2004年成为W3C推荐标准，2009年推出OWL2。OWL是一种基于描述逻辑（Description Logic）的本体语言，比RDFS具有更强的表达能力。OWL可以定义类的等价关系、属性的约束（如传递性、对称性）、复杂的类表达式（如交集、并集、补集），并支持机器自动推理。OWL有三种子语言：OWL Lite、OWL DL和OWL Full，其中OWL DL在表达能力和计算可判定性之间取得了最佳平衡，是工业应用中最常用的子集。

       ●SPARQL：2008年成为W3C推荐标准，是语义网的查询语言，类似于SQL之于关系数据库。

       ●SWRL（Semantic Web Rule Language）：扩展了OWL的规则表达能力，支持Horn规则形式的逻辑推理。

       这套技术栈的核心思想可以概括为：用形式化的、机器可处理的方式表达知识，使机器不仅能存储和检索数据，还能理解数据之间的关系、检测数据的一致性、从已有知识中推断出新知识。

       3.2 语义网与工业数据的相遇：早期的探索

       语义网技术诞生后，很快引起了工业界的兴趣。一个自然的想法是：能否用OWL等语义网技术来表达产品数据模型，从而解决STEP的语义封闭性问题？

       这一方向的早期探索中，最具代表性的是美国国家标准与技术研究院（NIST）的OntoSTEP项目。2008-2012年间，NIST的研究人员Raphael Barbau、Sylvere Krima、Sudarsan Rachuri、Ram Sriram等人系统研究了将STEP的EXPRESS模式翻译为OWL本体的可行性，并开发了Protégé插件工具。

       OntoSTEP的核心贡献包括：

       1.EXPRESS到OWL的映射规则：系统定义了EXPRESS构造（实体、属性、继承、聚合、SELECT类型等）到OWL构造（类、对象属性、数据属性、限制等）的映射规则。例如，EXPRESS实体映射为OWL类，EXPRESS属性映射为OWL属性，EXPRESS的SUBTYPE关系映射为OWL的SubClassOf关系。

       2.实例数据的翻译：不仅翻译模式（Schema，即TBox），还翻译Part 21文件中的实例数据（Instance，即ABox），使具体的CAD模型数据也能以OWL个体的形式存在。

       3.语义增强：将STEP的几何信息与NIST的Core Product Model（CPM）和Open Assembly Model（OAM）等非几何信息模型相结合，形成更丰富的语义产品模型。例如，在OWL中不仅可以表示“这是一个齿轮”（几何信息），还可以表示“这个齿轮的功能是传递运动”“它与轴之间是固定连接”（功能和行为信息）。

       4.推理与查询：利用OWL推理机（如Pellet）对翻译后的本体进行一致性检查、类层次推断和实例分类；利用SPARQL或SQWRL对集成后的知识库进行查询。例如，可以查询“找出所有具有'传递运动'功能的零件”——这种查询在传统的STEP文件中是难以实现的。

       OntoSTEP项目证明了EXPRESS到OWL的翻译在理论和技术上是可行的，也展示了语义网技术为产品数据带来的新能力：推理、查询、语义集成。然而，OntoSTEP本质上是一个研究原型，它依赖于Protégé桌面环境和Java技术栈，在处理大规模工业数据时面临性能瓶颈，也缺乏与现有工业软件系统的集成能力。

       与此同时，学术界也在更广泛地探讨产品数据的语义互操作问题。2005年，Patil、Dutta和Sriram在IEEE期刊上发表了一篇题为Ontology-Based Exchange of Product Data Semantic的论文，提出了Product Semantic Representation Language（PSRL）的概念，主张建立一种基于形式化描述逻辑的中间语言，使不同CAD系统之间的语义映射可以通过逻辑推理自动或半自动地确定。这篇论文系统阐述了语义互操作与语法互操作的本质区别：前者关注的是“意义的交换”，后者只关注“格式的转换”。

       这些研究工作为SST的诞生奠定了理论基础，但它们大多停留在学术原型阶段，未能形成可工业部署的产品。SST的独特价值，正在于它将这一方向的研究成果工程化、产品化，并与STEP的既有生态深度融合。

       3.3 “语义鸿沟”：为什么工业数据特别需要语义

       在讨论SST之前，有必要进一步阐明工业数据面临的“语义鸿沟”究竟是什么，以及为什么它比一般的互联网数据更难跨越。

       一般意义上的语义互操作问题——比如两个电商网站对“商品”的定义不同——可以通过建立简单的映射表来解决。但工业数据的语义问题要复杂得多，原因有三：

       第一，工业概念具有高度的领域专用性和精确性。“轴承”不是一个简单的字符串标签，它隐含了一整套工程知识：滚动轴承还是滑动轴承？内径多少？外径多少？宽度多少？公差等级？润滑方式？额定载荷？转速限制？这些属性之间有复杂的约束关系（例如，内径和额定载荷之间存在一定的统计关联）。两个系统对“轴承”的理解可能在这些属性的某个子集上重叠，但在其他子集上分歧，这种分歧不是简单的“同名异义”或“异名同义”，而是“部分重叠、部分相异”的复杂关系。

       第二，工业数据的生命周期极长。一架商用飞机的设计寿命是30—40年，一艘航母的服役期可能超过50年。在这期间，原始的设计系统可能已经更新换代多次，甚至原厂商可能已经倒闭。当30年后需要维修一个零件、追溯其设计意图时，如果当时的数据只是以某种专有格式存储的几何信息，而没有明确的语义描述，那么后人将很难理解这些数据的真实含义。这正是NIST在其Long Term Knowledge Retention（LTKR）项目中强调的问题：OWL等开放标准格式的优势在于其通用性和长期可用性，不像专有格式那样依赖于特定厂商的工具支持。

       第三，工业数据的来源极其多样。一个复杂产品（如飞机、汽车、船舶）的全生命周期数据，分散在数十甚至数百个不同的信息系统中：CAD系统负责几何设计，CAE系统负责仿真分析，PDM系统负责配置管理，ERP系统负责物料和成本，MES系统负责生产执行，SCADA系统负责设备监控，CMMS系统负责维护管理——每个系统都有自己的数据模型、自己的术语体系、自己的分类逻辑。要让这些数据在统一视图中被理解和使用，需要的不是简单的“数据搬运”，而是深层的“语义对齐”。

       这三个特征——领域专用性、生命周期长期性、来源多样性——共同构成了工业数据的“语义鸿沟”。跨越这一鸿沟，需要的不是更多的文件格式，而是一种能够将不同系统的概念框架显式化、形式化，并在统一的语义基础上进行对齐与验证的技术体系。这正是SST的使命所在。

四、SST的诞生：站在Lothar Klein四十年软件工程的肩膀上

       4.1 Lothar Klein与LKSoft：从PCB-CAD到STEP语义化的四十年征程

       SST不是凭空出现的。它的技术基因，深深植根于其创始人Lothar Klein在工业软件领域近四十年的持续耕耘，以及德国LKSoftWare GmbH（简称LKSoft）与中国德中（天津）技术发展股份有限公司（简称德中技术，DCT）之间长达十余年的深度合作。

       Lothar Klein的职业生涯，堪称一部从电子设计到工业数据标准化的个人技术编年史：

       1983-1993：ColorCAM——PCB-CAD/CAM的先驱

       1983年，MS-DOS16位个人计算机启蒙时代，大多数 CAD 软件还锁在昂贵的工作站和大型机里， Lothar Klein就已经推出了LAYCAD—后来演变为 ColorCAM—这是一款运行在个人机上的PCB-CAD/CAM软件， 也是最早的板级EDA+CAM（Electronic Design Automation）工具之一。在图形硬件与主机分离的年代，ColorCAM为印制电路板的设计和制造提供了早期数字化工具。它最初运行在 ELTEC（美因茨）和 HEMA（阿伦）基于 Motorola 6809 的计算机上，借助内存窗口技术突破了 16 位地址空间的 64KB 限制；1984 年移植到 IBM AT 后，又因当时的 CGA 显卡分辨率不足，把图形子系统做成了外置"图形盒"（后经 Hitachi HD63484 控制器达到 1600×1200 四色显示）。ColorCAM 主体以 Pascal 编写，支持多达 120 个构造层，符号化数据存储、Joystick 交互；因主机算力不足以运行自动布线，迷宫布线等算法被放到了 INMOS Transputer 扩展板上执行—— maze runner、拆线再试（rip-up and retry）等布线策略即源于这一时期。软件的PCB设计功能采用动态内存管理，库、原理图、PCB布局、布线功能齐全，满足当时模拟、数字、数模混合、HF各种电路板设计；其计算机辅助制造（CAM）功能，通过统一的数据中间层，支持不同的输出设备，包括矩阵打印机、笔式绘图仪，包括驱动光绘机的接口，而且包括直接驱动LPKF公司的CNC钻铣设备的接口，实现了物理方法制造电路板的技术。ColorCAM 不只是一个设计工具，而是把软件与硬件加工设备深度绑定——让设计数据直接驱动CNC设备完成物理加工，将信息作业与物质作业的统一在一个系统中。到1993年Windows兴起不到十年间，基于DOS的ColorCAM取得了超过1000个应用许可。这段经历奠定了Lothar Klein "设计数据 → 工程数据 → 物理实现"一以贯之的技术轨迹，烙印下了他对电子制造数据管理的深刻理解和长期技术直觉。

       1988-1993：EDIF标准与EDIF-PI——电子设计交换格式的早期实践

       1988年起，Lothar Klein开始参与ANSI/EIA标准EDIF（Electronic Design Interchange Format，电子设计交换格式）的软件开发。EDIF是电子设计领域EDA/CAD 工具间最早的标准化数据交换格式之一，广泛应用于网表（net-lists）的互联互通。Lothar Klein基于ANSI/EIA EDIF 200标准开发了软件库EDIF-PI（PI=Procedural Interface最初用C语言，后迁移至C++），用于操作EDIF数据及类似格式。通过EDIF-PI，Lothar Klein把EDIF/S-expression式电子设计数据变成可操作、可复用的软件库；随后又将其产品化为CircuitCAM 的 .cam/EDIF-like 数据流程，完成了EDIF 200生态的商业实现。随着IEC EDIF 300（1993年发布）和EDIF 400（1996年发布）的演进，EDIF-PI成为该领域广泛使用的底层数据操作工具。这段经历使Lothar Klein深刻理解了“标准数据交换接口”在工程实践中的核心价值，也为后来开发STEP相关的SDAI接口埋下了伏笔。

       1991年至今：CircuitCAM—面向 PCB/SMT/光伏（PV）行业的直接加工 CAM软件

       1991年，Lothar Klein开始开发CircuitCAM，聚焦面向制造的专业CAM软件，为SST所需的“中立产品数据建模、异构CAD/CAM数据交换与校验、几何/拓扑/网表一致性处理、高性能工程数据管理与版本化数据组织”提供了实践经验。该系统面向MS-Windows 32/64 位计算机，以C/C++编写，支持从原型制造到批量生产的全流程数据准备。除裸印制电路板制造数据处理外，CircuitCAM的图形能力较强，在两个专业方向形成长期商业化应用：一是生成面向机械/激光去除材料的加工路径（toolpath）工程数据，用于直接制造导电图形和阻焊图形，可省去传统曝光、显影、蚀刻所需的设备、材料与流程；二是设计精密漏印模板，用于转移和分配功能性材料，如SMT锡膏、光伏导电银浆或其他导电浆料。2014年，LKSoft以CircuitCAM相关权利/业务作价投入中国德中技术，成为其工业软件产品线的重要组成部分。CircuitCAM 早在 LKSoft 与 LPKF 合作的时期（2010 年之前）全球付费许可即已超过一万套，此后迭代的 V7、V8 版本仍在持续增长。CircuitCAM 的原生直接加工能力，包括SMT锡膏钢网设计、光伏及电子行业漏印导电结构的精密钢丝网/模板设计，已迭代多轮，并在 2024 年升级至CircuitCAMV8.0 的基础上持续更新。其裸PCB制造与电路板装联（SMT）功能—涵盖数据导入与解析、封装识别与管理、图形编辑与可制造性检查（DFM）、工艺补偿、拼板、钻孔与外形/内形加工、网表比对与电气一致性检查、生产文件输出、可视化查看与测量—已从早期面向小批量、多品种的机械/激光直接加工，扩展到支持规模化批量生产，成为数字制造和直接制造数据处理中的方案之一。

       1995至今：JSDAI——Java世界的STEP数据访问接口

       1995年，随着STEP标准进入工业应用阶段，LotharKlein启动了JSDAI（Java Standard Data Access Interface）项目。JSDAI是基于ISO10303-22（SDAI，标准数据访问接口）和ISO10303-27（Java语言绑定）的Java实现，也是目前最成熟、功能最丰富的SDAI实现之一。JSDAI的核心能力包括：

       ●模式编译器：将EXPRESS模式文件编译为Java类，使开发者可以直接用Java代码操作EXPRESS实体和实例；

       ●Part21读写：支持STEP物理文件（Part21格式）的解析和生成；

       ●数据库后端：JSDAI-DB支持将STEP数据持久化到关系数据库中，支持大规模数据的高效查询和更新；

       ●多模式支持：可以同时加载和操作多个EXPRESS模式，支持模式之间的交叉引用。

       JSDAI自v4.0.0起提供Eclipse平台插件，形成强大的IDE集成开发环境。2013年起，JSDAI以AGPLv3许可证开源发布，成为STEP社区重要的开源基础设施。NIST的OntoSTEP项目在进行EXPRESS到OWL的实例翻译时，就使用了JSDAI作为底层数据访问引擎。可以说，JSDAI是连接“传统STEP世界”与“现代编程世界”的桥梁。

       1995至今：IDA-STEP——STEP数据的桌面工作站

       与JSDAI面向开发者不同，IDA-STEP（Integration Distributed Applications on the basis of STEP）是面向终端用户的桌面应用程序。IDA-STEP基于Eclipse平台开发，提供了一整套查看、编辑、验证和转换STEP数据的功能，包括：

       ●多格式支持：可以打开和查看STEP Part21文件、Part28（XML编码）文件以及其他相关格式；

       ●树形浏览器：以层次化的树形结构展示STEP数据，用户可以展开实体、查看属性、导航关联；

       ●3D可视化：集成几何引擎，可以渲染STEP文件中的3D模型，支持旋转、缩放、剖切等操作；

       ●数据验证：根据EXPRESS模式的约束规则，验证数据的一致性和完整性；

       ●GD&T编辑器：支持在3D实体模型上创建和编辑几何尺寸与公差（GD&T）标注，实现基于模型的定义（MBD）；

       ●AP242支持：自2011年发布的 v4.5起支持STEP AP242 "Managed Model Based 3D Engineering"——彼时AP242尚处于委员会草案（CD）阶段，IDA-STEP是首批跟进的应用之一。

       至2013年，IDA-STEP 已在 PDES TAC上展示了面向AP242的语义级 PMI 能力：15类几何公差、可独立命名与复用的基准系（Datum System）、ISO/ASME全部修饰符、带关联性的公差标注与剖切视图（Saved Views），公差语义可直接在三维模型上编辑、校验并用于下游的公差累积分析与检测规划。

       IDA-STEP的价值在于：它使STEP数据不再是只有程序员才能处理的“黑盒”，而是普通工程师也能直观理解和操作的“白盒”。2020年，IDA-STEP被德中技术（DCT）中国收购，与JSDAI一起构成了德中技术在STEP领域的核心软件资产。

       2006-2008：S-TEN研究项目—语义网与STEP的早期交汇

       2006至2008年间，LKSoft参与了欧洲S-TEN研究项目。该项目使用ISO 15926-2的概念和OWL来处理STEP数据模型和数据，是语义网技术与工业产品数据标准融合的最早实践之一。S-TEN项目验证了将STEP的EXPRESS模型映射到OWL本体的可行性，也暴露了早期方案在性能和实用性上的局限。这些经验教训，直接影响了后来SST在架构设计上的关键抉择——例如放弃通用推理、采用显式语义声明和封闭世界假设。

       2016至今：BAOBAB+与ALOES——后勤支持分析的语义化实践

       自2016年起，LKSoft为法国NexterSystem开发了BAOBAB+，这是一款基于AIA/ASD S3000L（后勤支持分析标准）和PLCS（STEP AP239，产品全生命周期支持）的LSA数据合并工具。此前，LKSoft还开发了ALOES后勤支持分析系统，最初基于MIL-STD-1388和NPDM（NATO Product Data Model，与STEPAP203/214类似）。这些项目使LKSoft深入理解了产品数据在军事装备全生命周期管理中的复杂性，也为SST处理后勤支持分析（LSA）数据（ASD S3000L）积累了直接经验。

       4.2 SemanticSTEP.org：承载LKSoft与NexterSystem语义网技术的联合活动

       在今天的SST正式诞生之前，LKSoft与NexterSystem早在2000年代后期就联合开展了一系列的语义网活动，以SemanticSTEP.org网站（www.semanticstep.org）为载体，呈现了两个实体“涉及STEP数据模型、STEP数据以及相关标准及其利用语义网技术的各种活动的集合”。这个联合活动，旨在探索如何将W3C语义网技术应用于ISO 10303（STEP）、ISO 15926（过程工厂生命周期数据集成）、ISO13584（零件库，PLIB）等工业数据标准。

       早期LKSoft与NexterSystem 的联合活动涵盖多个研究方向：

       ●Oil&Gas：探索ISO15926在石油天然气行业的应用；

       ●S-TEN：记录欧洲S-TEN研究项目中语义网与STEP数据结合的经验；

       ●STEP：整理STEP标准相关的技术资源和工具；

       ●S3000L&S3KL Ontology：研究后勤支持分析标准S3000L的本体化表达。

图4.1 SemanticSTEP技术早期的网站
（来源：2026年9月13日互联网，网址，https://www.semanticstep.org/）

       www.semanticstep.org所呈现的活动内容，是今天SST技术的“史前孵化器”—它汇聚了LKSoft在语义网与工业标准交叉领域的早期探索成果，也为后来SST的系统性架构设计提供了概念验证和经验积累。2026年，随着SST-Corev1.0.0和SST-EDM MVP版的正式发布，LKSoft、SemanticSTEP Technology GmbH与德中技术新近的活动已全面迁移至www.semanticstep.com。

图4.2 SST/Semantic STEP Technology今天的网站（来源：2026年9月13日互联网信息，网址，https://www.semanticstep.com）

       4.3 德中技术（DCT）：中德协同的工业软件与装备平台

       德中（天津）技术发展股份有限公司（DCT Co., Ltd.）成立于 1998 年；其前身可追溯到 1994 年依托中德技术培训中心设立的中德技术发展责任有限公司。DCT 长期深耕工业软件与精密装备，业务包括：

       ●激光微加工设备：面向去除、切割、钻孔等精密结构加工；

       ●PCB生产成套设备：服务原型制造与小批量、多品种电路板加工；

       ●工业软件：包括 CircuitCAM（CAM 数据准备）、IDA-STEP（STEP 数据查看与编辑）、DreamCreator/DCT MOS（CNC 机床驱动）、DAO（运动控制硬件与嵌入式软件）、EDWin（PCB 板级 EDA），以及自 2020 年起开发的 SST 与 SST-EDM。

       DCT创业者与Lothar Klein工业软件体系的接触较早：1980年代中期已开始应用ColorCAM及其所支持的CNC设备进行PCB设计与制造；1980年代末至1990年代中期，在中德培训中心工作期间开设ColorCAM、Tango、Protel及电气、机械相关课程，推广CAD/CAM技术；1990年代末至2000年代初，开展Protel、EPLAN的商业化推广销售，并借助所创的乐普科（天津）光电平台，推广销售CircuitCAM与 EDWin。这些经历为DCT今天在工业软件领域的发展积累了客户、渠道与制造数据know-how。

       2014年LKSoft以CircuitCAM相关权利/业务投入DCT后，Lothar Klein及LKSoftWare的EDIF/STEP/CAM数据经验，与 DCT的CircuitCAM、IDA-STEP、EDWin产品线汇合，形成了紧密合作关系和中欧协同的团队，使SST/SST-EDM项目能够同时利用德国的技术积淀和中国的工程实施能力，构成2020年后SST/SST-EDM开发的产业基础。

       4.4 从JSDAI、IDA-STEP到SST：为什么需要一次架构跃迁

       JSDAI和IDA-STEP代表了STEP技术在2000-2010年代的最高工程水平。但它们也共享一个时代局限：它们本质上仍然是“STEP世界”内的工具。JSDAI让Java程序能操作STEP数据，IDA-STEP让用户能可视化和编辑STEP数据，但它们都没有解决STEP数据如何与“非STEP世界”（如ERP、MES、物联网平台、知识图谱、AI系统）进行语义级交互的问题。

       具体而言，JSDAI/IDA-STEP时代的技术面临以下挑战：

       1.技术栈老化：JSDAI基于Java，IDA-STEP基于Eclipse桌面平台。在当今云原生、微服务、容器化的技术环境中，这些技术栈显得沉重而难以集成。

              2.数据孤岛：STEP数据被封闭在文件或专用数据库中，难以与Web服务、REST API（Representational State Transfer API）、GraphQL等现代数据交换方式对接。

       3.语义缺失：JSDAI能精确地按EXPRESS模式的定义操作数据，但它并不提供将这些数据的语义暴露给外部系统的能力。例如，一个基于JSDAI的应用程序知道“这个实例是product类型，它的id是123”，但它无法以标准化的方式告诉外部系统“id为123的product是一个齿轮箱，属于某型号发动机，由某供应商制造”。

       4.扩展困难：当需要在STEP数据模型之上增加新的语义层（如功能模型、行为模型、仿真模型）时，传统STEP工具缺乏灵活的本体扩展机制。

       5.推理能力缺失：EXPRESS模式的约束主要是语法和结构层面的（如类型检查、基数检查），不支持逻辑推理。无法自动回答“如果A是B的零件，B是C的零件，那么A是否也是C的零件？”这类需要传递性推理的问题（除非在应用程序代码中硬编码）。

       这些挑战，本质上都是“STEP数据缺乏语义开放性”的表现。解决这些挑战，需要的不是对JSDAI或IDA-STEP的修修补补，而是一次架构层面的跃迁：将STEP的数据模型与语义网的技术栈深度融合，使STEP数据既能保留其精确性和完整性，又能获得语义网的开放性、可验证性与可集成性。

       这正是SST（SemanticSTEP Technology）的设计目标。

       4.5 SST的启动与演进

       2020年初，德国的SemanticSTEP Technology GmbH（LKSoft专注于SST技术后的公司）与中国的德中技术（DCTCo.,Ltd.）启动了SST联合软件开发项目。LotharKlein基于其近40年的软件开发经验，就如何为各类CAx相关Web应用创建全新框架做出了一系列重大决策。这些决策构成了SST的核心设计基因：

       ●GO语言：选择Go作为服务端主要编程语言，以获得云原生环境下的高性能和并发能力；

       ●RDF/S+Turtle：以RDF/S作为存储所有应用数据和高层本体的基础，以Turtle格式可视化数据；

       ●NamedGraph+派生数据库：以NamedGraph（可包含大量三元组）作为数据库中持久化数据存储的主要对象，将查询需求分离到独立的派生数据库中，可针对任何所需索引进行优化——这与使用SPARQL作为主要访问机制的传统RDF存储方案截然相反；

       ●内存Triplex结构：支持从主语、宾语、谓语三个方向高速遍历RDF三元组图；

       ●OWL2+封闭世界假设（CWA）：使用OWL作为数据建模的逻辑基础，但不依赖基于开放世界假设的通用推理；相反，要求对每个节点（IRI及空白节点）显式声明其类型，以便基于封闭世界假设进行验证；

       ●owl:import与Dataset：利用OWL2的owl:import机制，显式声明哪些NamedGraph属于定义封闭世界验证范围的数据集；

       ●GIT式版本控制：基于NamedGraph实现原生GIT式修订控制能力，具备完整的提交（commit）、分支（branch）、差异比对（diff）和合并（merge）功能；

       ●早绑定（EarlyBinding）支持：将关键类和属性直接作为Go对象访问，显著简化转换器等开发工作。

       2023年5月，SST-Core基本功能的第一个预发布版本交付给一位工业客户，该客户已将其用于生产级Web应用。此后，编程接口得到显著优化，缺失功能被逐一补充。2026年4月27日，德中技术与德国SST有限责任公司联合发布SST-Core v1.0.0，以双重许可模式（商业许可+PolyForm非商用1.0.0许可）提供，源代码发布于GitHub（https://github.com/semanticstep/sst-core）。2026年7月，SST-EDM MVP（最小可行产品）正式上线（https://edm.semanticstep.net/），首个支持领域为基于IEC/ISO 81346参考命名系统（RDS）的分解结构管理。

五、SST的技术原理与架构

       5.1 核心思想：为STEP数据赋予语义网的“灵魂”

       SST的技术原理可以用一句话概括：将ISO 10303的EXPRESS信息模型中的概念经取舍整合后映射为W3C的OWL本体，将STEP物理文件中的实例数据映射为RDF图数据，使其中的实体、属性和关系获得机器可处理的显式语义，并为语义关联、数据验证、跨模型集成以及进一步的知识化应用提供统一的数据基础。

       需要强调的是，SST并不是"把STEP转成RDF、再交给通用的SPARQL查询与OWL推理系统"的路线。数据访问与验证由SST自己的机制承担：Repository API管理Dataset/NamedGraph主数据，Triplex三向结构支持内存中的图遍历，Bleve派生索引支持面向应用的查询，验证引擎基于封闭世界假设执行一致性检查。关于"推理"的准确说法是：RDF/OWL为SST提供了表达语义的基础，而语义究竟能被机器怎样利用，取决于其上实现了怎样的软件机制——详见5.5节与第六章。

       这个映射不是简单的“格式转换”，而是深层的“语义对齐”。SST需要解决三个核心问题：

       1.模式映射：如何将EXPRESS的建模构造（实体、属性、继承、聚合、约束等）精确地映射为OWL的建模构造（类、属性、限制、公理等），同时保留EXPRESS的语义约束？

       2.实例映射：如何将Part21文件中的实例数据（实体实例、属性值、聚合值、引用关系等）映射为RDF三元组，同时保持数据的一致性和可追溯性？

       3.语义增强：如何在保留原有STEP语义的基础上，为数据添加新的语义层（如领域本体、功能模型、行为模型），并支持跨本体的语义关联与联合解释？

       下面逐一讨论SST对这三个问题的解决方案。

       5.2 模式映射：从EXPRESS到OWL

       本节所述的映射问题与通用解法，主要依据OntoSTEP等公开研究成果；SST的具体实现细节以SST-Ontologies源码为准。

       EXPRESS和OWL是两种截然不同的建模语言。EXPRESS是一种数据建模语言，强调精确的数据结构和约束；OWL是一种本体语言，强调概念之间的逻辑关系和推理能力。SST的模式映射，需要在两者之间找到精确的对应关系。

       5.2.1 基本构造的映射

       以OntoSTEP为代表的EXPRESS-to-OWL映射研究建立了如下基本规则，SST在此领域公共知识的基础上实现自己的本体构建。下表以OntoSTEP的做法为代表：
       这些映射规则看似直接，但深入细节时会遇到许多微妙的问题。

       需要向读者说明的是：上表描述的是该领域多年积累的通用映射规则，用于说明EXPRESS→OWL映射的技术要点；SST的具体词汇、类层级与结构以SST-Ontologies源码（lci、sso、rep、qau等本体文件）为准，并未对OntoSTEP规则逐条照搬——这正体现了SST"取其精华、去其繁复"的策略（见4.5节）。

       5.2.2 开放世界与封闭世界的调和

       EXPRESS和OWL在基本假设上存在一个根本差异：封闭世界假设（Closed World Assumption, CWA）与开放世界假设（Open World Assumption, OWA）。

       在EXPRESS中，如果一个实例没有声明某个属性的值，那么系统默认该属性不存在（即值为“未提供”或“未知”）。如果一个属性不是OPTIONAL的，那么缺少值就是一个错误。这种假设是“封闭世界”的：系统所知道的就是全部，未知即不存在。

       在OWL中，如果一个实例没有声明某个属性值，推理机不会认为这是一个错误——它只是“不知道”这个值。因为OWL假设世界是开放的：总有更多的信息可能存在，只是当前还没有被陈述。这种假设是“开放世界”的：未知不等于不存在。

       这个差异在映射时必须仔细处理。例如，在EXPRESS中，如果实体product的id属性是必需的（非OPTIONAL），那么任何缺少id的product实例都是无效的。但在OWL中，即使product类对id属性有基数限制，缺少id的实例也不会被推理机标记为不一致——因为推理机假设“也许这个id存在于某个我们还没看到的地方”。

       为了解决这个问题，映射实践中通常需要添加额外的OWL约束或SWRL规则，来模拟EXPRESS的封闭世界语义。例如，可以通过声明“每个product实例必须恰好有一个id值”，并配合特定的推理配置，来使OWL推理机能够检测到缺失id的不一致性。这种调和是EXPRESS→OWL映射中最具技术挑战性的部分之一。SST则通过另一条路径绕开了这一难点：不依赖推理机，要求基础信息全部显式声明，以基于CWA的验证取而代之（见4.5节的设计基因）。

       5.2.3 聚合类型的映射

       EXPRESS提供了四种聚合类型：SET（无序不重复）、BAG（无序可重复）、LIST（有序可重复）、ARRAY（有序、固定大小、可重复）。OWL的属性本质上是二元关系，不直接支持聚合的语义（尤其是顺序和重复）。

       处理聚合映射的典型做法是'包装器'模式（OntoSTEP 即采用此法）。以BAG为例：假设EXPRESS中有一个实体Container，它有一个BAG类型的属性items，元素类型为Content。在OWL中，映射会创建以下结构：

       ●Container类有一个属性has BagItem，指向BagItem类。

       ●BagItem类有两个属性：has Content（指向Content类，基数为1）和has Index（整数类型的数据属性，用于标识重复项）。

       ●当Container的BAG中包含两个相同的Content实例时，在OWL中会创建两个不同的BagItem实例，它们都指向同一个Content实例，但通过不同的hasIndex值来区分。

       这种模式虽然增加了本体的复杂度，但精确地保留了BAG的“可重复”语义。SET、LIST和ARRAY的映射也采用类似的策略，只是在是否保留顺序、是否允许重复等细节上有所不同。

       5.2.4 抽象实体与多重继承

       EXPRESS支持ABSTRACT关键字，表示一个实体不能被直接实例化，只能作为超类型被继承。OWL没有直接的“抽象类”概念，但可以通过声明“超类的实例集等价于所有子类的实例集的并集”来模拟这一语义。如果某个实例被声明为抽象类的实例，但不是任何子类的实例，推理机就能检测出不一致性。

       EXPRESS还支持复杂的继承组合：ONEOF（互斥继承，实例只能属于一个子类）、ANDOR（默认继承，实例可以属于多个子类）、AND（联合继承，实例必须同时属于所有子类）。这些在OWL中分别通过disjoint Classes（互斥类）、union Of（并集类）和intersection Of（交集类）来表达。

       5.3 实例映射：从Part21到RDF

       模式映射解决了"数据模型如何表达"的问题，实例映射则解决"具体数据如何表示"的问题。STEP物理文件（Part21）采用明文编码：每个实例一行，格式为 "#id=EntityType(attr1, attr2, …)"，实例之间通过 "#id" 引用建立关联。SST的STEP P21 Converter依据本体中声明的STEP实体映射规则（ssmeta:stepImEntityMap、ssmeta:stepImMapAttributeOrder），将Part21实例转换为RDF三元组：每个实例成为某个NamedGraph拥有的IBNode（新节点默认采用UUID-URN标识），每个属性值成为以该节点为主语的三元组，实例间引用成为图内的对象属性边。加载后的实例图与本体类层次对齐，即可直接接受SST验证引擎的CWA一致性检查。

       这种映射的关键优势在于：一旦STEP实例数据进入RDF图，它就可以与任何其他RDF数据连接。例如，可以在不修改原始STEP数据的前提下，将product实例与外部知识图谱中的供应商信息关联起来，形成跨数据源、跨命名空间的语义链接——这是STEP传统技术栈无法实现的。

       5.4 语义增强：超越几何的产品知识

       SST的价值不仅在于“把STEP数据翻译成OWL”，更在于“在OWL框架下为产品数据添加新的语义层”。

       传统的STEP应用协议（如AP203、AP214）主要关注几何和物理属性信息。但一个产品的完整知识远不止于此：它还包括功能（这个零件是做什么的）、行为（它在工作中如何表现）、需求（它必须满足什么条件）、约束（它受什么限制）、设计原理（为什么选择这种方案）等“超越几何”（beyond-geometry）的信息。

       在SST框架下，这些超越几何的信息可以用独立的OWL本体来表达，然后与STEP数据本体进行语义集成。例如：

       ●可以使用NIST的Core Product Model（CPM）本体来表达产品的功能-形式-行为结构。

       ●可以使用SysML或特定领域的本体来表达产品的系统架构。

       ●可以使用自定义的领域本体来表达特定行业的专业知识（如航空领域的适航要求、汽车领域的排放标准）。

       这些本体与STEP本体的集成，不是简单的“数据合并”，而是通过语义等价声明（个体层面的等价用owl:sameAs，类层面的等价用owl:equivalentClass）和跨本体映射规则（如SHACL形状约束）来实现的。例如，可以在类层面声明"CPM本体中的Artifact类与STEP AP203中的product实体语义等价"（owl:equivalentClass），或在个体层面用owl:sameAs声明两个系统中的实例指向同一现实对象。其效果是：应用能够在明确映射关系的基础上，联合解释和处理不同领域的语义信息——而不是由推理机"自动继承"任何未显式声明的内容。

       这种语义增强的能力，使SST能够支持传统STEP技术无法实现的高级应用：

       ●设计意图追溯：从几何模型追溯到功能需求和设计原理。

       ●变更影响分析：当某个需求或约束发生变化时，自动识别受影响的几何元素。

       ●跨域知识融合：将设计知识、制造知识、运维知识在统一的语义框架下关联起来。

       ●智能搜索与推荐：基于语义相似性而非文本匹配，在产品库中搜索相关设计。

       5.5 SST的技术架构

       SST的技术架构采用分层设计，核心组件包括：

       第一层：语义内核（SST-Core）

       SST-Core是采用Go语言实现的语义数据引擎与API 库，为基于SST本体的应用提供数据访问、存储、验证及修订管理能力。其核心服务包括：

       ●本体编译与早绑定支持：读取SST本体文件（.ttl），生成相应的Go访问代码，使开发者能通过与本体中类和属性对应的程序接口操作数据（早绑定）；同时提供通用的晚绑定访问接口；

       ●数据导入服务：将Part21文件解析并转换为RDF图数据，支持批量导入和流式导入；

       ●验证引擎：基于封闭世界假设（CWA），通过显式类型声明对数据进行一致性验证；

       ●查询能力：对主数据经Repository API直接访问；内存中经Triplex三向结构遍历；面向应用的全文与字段查询经Bleve派生索引完成——主数据存取与灵活查询相互解耦；

       ●GIT式版本控制：基于Named Graph实现完整的提交、分支、差异比对和合并功能。

       部署形态：SST-Core基于Go实现（Go 1.25），SST Repository支持本地（嵌入式）与远程部署，由BBolt（主数据）、Bleve（派生索引）与Document Vault（非 RDF 文档）组成；认证与访问控制基于OAuth2/Keycloak（OIDC），支持RBAC与配额管理。整体面向云原生环境，可容器化部署。

       第二层：领域应用层（SST-EDM）

       在语义内核之上，SST支持构建面向特定领域的应用程序。目前已开发的领域应用包括：

       ●SST-EDM（Engineering Data Management）：工程数据管理系统，支持多源异构工程数据的集成、版本控制和协同工作。当前聚焦CAD、CAM、ERP、PDM相关数据，首个支持领域为基于IEC/ISO 81346参考命名系统（RDS）的分解结构管理。电气线束设计（EWIS）功能正在开发中，并将直接支持基于STEP AP242（ISO 10303-242:2025）的数据交换。

       第三层：集成与扩展层

       SST提供与外部系统的集成能力，包括：

       ●与CAD/CAE系统的集成：通过插件或API，将SST的数据管理能力嵌入到主流设计工具中。

       ●与PDM/PLM系统的集成：通过标准化的数据接口，实现与现有产品数据管理系统的双向同步。

       ●与物联网平台的集成：将SST管理的产品设计数据与物联网传感器数据关联，支持数字孪生应用。

       ●与AI/ML平台的集成：为机器学习模型提供结构化的、语义明确的训练数据，支持基于知识图谱的AI应用。
       图5.1展示了SST的完整技术栈。右侧绿色部分是SST Core库与工具集：最上层是各类电气线束数据（KBL、VEC、Capital Harness等）的导入器，其下依次是命令行工具SST CLI、STEP AP242域模型与 MIM 模型的导入/导出模块、SST的分割/差异/合并功能、数据验证模块，以及最底层的SST本体编译器——后者读取开放的本体文件（.ttl）生成早期绑定代码。中间黄色部分是SST Core的三元组内存结构（Triplex）与双模式API（Late Binding / Early Binding），通过gRPC或本地调用访问左侧的SST Repository；Repository由BBolt（主数据与修订历史）、Bleve（派生查询索引）和Document Vault（非RDF文档存储）三部分组成，支持本地与远程部署。图左上方是用户与上层应用（EDM-Client、EDM-Services等Web应用），经OAuth2/Keycloak认证后访问系统。右下角是SST词汇表/早期绑定数据模型，即参考数据（IEC 61360、量与单位等）、STEP采纳的ISO 10303数据模型、ISO 15926-2/-12生命周期概念与W3C语义网标准的统一载体。
       图5.2给出了SST高层本体的骨架。最顶层是Thing，下分Activity与Event两大分支，通过 begins/ends、temporalPartOf、participatIn、partOf、containedBy等一系列带逆属性的关系（椭圆表示）与Individual相连；Individual之下特化为ArrangedIndividual与Feature。这一骨架衍生自ISO/TS 15926-12的四维时空个体（4D）模型：hasPart/partOf被声明为严格偏序关系，并细分为arrangedPartOf、assembledPartOf、featureOf 等专用化属性（部分论Mereology的工程化表达）。在此骨架之上，SST挂接了三类本体：rep（采纳ISO 10303-43/-42等的几何、拓扑、运动学表示）、sso（AP242派生的PDM概念，现特化为lci的子类）、qau（ISO 80000 量与单位）。右侧还接入了ISO/IEC 81346参考命名体系与PLIB零件库类（ISO 13399、IEC 61360、eClass等）及国家代码、货币代码、颜色等枚举型参考数据。

六、SST的核心功能

       基于上述技术原理和架构，SST提供了一系列传统STEP工具所不具备的核心功能。这些功能可以归纳为以下六个方面。

       6.1 语义化的数据存储与查询

       传统STEP数据以文件形式（Part21）存储，查询需要解析整个文件并按模式结构遍历。SST将数据组织为RDF图，但其查询路径与典型的SPARQL存储引擎不同：对Dataset、NamedGraph及其Revision等主数据，通过Repository API直接访问；数据加载到内存后，通过Triplex三向结构从主语、谓语、宾语任意方向高效遍历RDF图；对于全文检索、字段检索及应用特定查询，则通过Bleve建立可定制的派生索引。由此，SST将主数据的高效存取与面向应用的灵活查询能力解耦。

       以"查找所有材料为不锈钢且半径大于50mm的圆柱面"为例：应用程序经Repository API签出包含几何数据的Dataset，加载至内存后从 advanced_face个体出发，沿face_geometry关系找到cylindrical_surface，读取其半径字面量进行数值比较，再沿关联路径找到材料个体完成过滤——全程是确定性的 API 遍历，不依赖图模式查询引擎的解析与优化。对"找出所有描述中提到'轴承座'的文档"这类全文需求，则走 Bleve 派生索引。

       6.2 逻辑验证与一致性检查

       SST使用RDF/OWL表达数据类型、关系及约束，并采用基于封闭世界假设的验证机制。它强调必要信息的显式声明，在确定的数据集范围内检查数据是否符合模型要求。结合本体定义、验证器支持范围及应用配置，验证内容可以涉及以下方面，并可根据工程需求扩展：

       ●类层次验证：如果A是B的子类，B是C的子类，那么A的实例必须满足C的所有约束。

       ●属性链验证：如果A与B有part_of关系，B与C有part_of关系，且part_of被声明为传递性属性，那么系统可以验证A与C的part_of关系是否被正确维护。

       ●不一致性检测：如果某个实例同时被声明为两个互斥类的成员，或者违反了某个基数约束，系统能够自动标记这种不一致性。例如，如果一个实例被声明为既是“旋转体”又是“非旋转体”，系统会立即报错。

       ●显式类型检查：基于CWA，系统要求每个实例必须显式声明其类型，缺失类型声明即视为错误。

       这些验证能力，使SST能够充当一个“智能数据管家”：它不仅存储数据，还能理解数据的内在逻辑，自动发现隐含关系和潜在错误。

       6.3 多模式集成与联邦查询

       一个复杂的工业产品往往涉及多个EXPRESS模式。例如，一个航空发动机可能同时涉及AP203（几何设计）、AP209（复合材料）、AP210（电子装配）、AP239（全生命周期支持）等多个应用协议。传统方式下，这些模式的数据分散在不同的文件中，难以统一查询。

       SST支持将多个EXPRESS模式的概念经取舍整合后编译为OWL本体（见5.2.1节），并在统一的RDF图中存储来自不同模式的数据实例。通过OWL的import机制和跨本体映射，SST可以建立不同模式之间的语义关联。例如，可以声明“AP203中的product与AP239中的Product是等价类”，从而使跨模式的查询成为可能。

       更进一步，SST Repository 支持远程同步（remote-to-remote sync）：数据可在多个仓库之间无损复制与对齐。这为分布在不同组织、不同地理位置的产品数据在统一语义框架下的协同访问奠定了数据基础——至于跨仓库的联合查询机制本身，则是可以设想的后续演进方向。

       6.4 版本管理与变更追溯

       产品数据在全生命周期中会经历频繁的变更。SST利用Named Graph和GIT式机制，支持细粒度的版本管理：

       ●以NamedGraph和Dataset为版本单元：版本管理作用于NamedGraph与Dataset，每次提交（Commit）保存一组图的修改快照，保留变更前后的完整状态。

       ●差异自动计算：变更之间的差异可以通过图差异算法自动计算。

       ●提交元数据：每次Commit携带提交说明、提交者与时间戳，以键值形式存储于BBolt主数据库（而非RDF三元组），审计信息完整、独立可查。

       ●历史检出：通过Commit哈希值或分支名称，可以检出任意已保存的历史状态，或比较不同版本之间的差异。

       这种版本管理能力，对于需要严格变更控制的行业（如航空、医疗、核能）尤为重要。

       6.5 开放链接与知识图谱构建

       SST中的每个资源都以URI（UUID-URN 或 URL）标识，数据可以无损导出为标准RDF/Turtle文件；远程Repository之间支持同步复制。这为SST数据与外部知识库、跨企业数据集的语义关联提供了技术方案——任何系统只要理解RDF，就可以消费SST输出的数据。

       这意味着，SST管理的产品数据为融入更广阔的Web of Data提供了开放基础。一个企业的SST数据仓库，可以成为该企业知识图谱的核心节点；多个企业的SST数据仓库，可以通过标准的Linked Data协议相互链接，形成跨组织的工业知识图谱。

       6.6 可扩展的领域应用开发

       SST的语义内核提供了一套通用的数据管理和验证能力，上层应用开发者可以在此基础上快速构建领域专用工具。SST-EDM就是一个典型例子：它不需要从头实现EXPRESS解析、数据存储和查询功能，而是直接调用SST内核的API，将开发重心放在工程数据管理的专业逻辑上（如分解结构管理、线束布线算法、电气规则检查、BOM生成等）。

       这种分层架构大大降低了领域应用开发的门槛，使SST生态能够快速扩展到新的工业领域。

七、SST的技术特色

       将SST与现有的产品数据技术进行对比，可以更清晰地看出它的独特价值。

       7.1 与原生STEP工具的比较
       7.2 与通用语义网平台的比较
       7.3 与PLM/PDM系统的比较
       7.4 SST的核心特色总结

       综合以上比较，SST的核心特色可以概括为四点：

       特色一：开放标准的深度融合。SST不是创造新的标准，而是将三大成熟的标准系列——W3C语义网标准（RDF/OWL，提供语义表达与数据组织的语法基础）、ISO 15926标准（提供全生命周期的4D本体框架）、ISO 10303（STEP，提供工业产品数据的几何与PDM语义）——进行独特组合与取舍融合。它既保留了STEP在工业数据建模方面的权威性和精确性，又获得了语义网在开放性与可链接性方面的优势，并以ISO 15926补上了时间维度。这种"强强联合"，使SST站在了巨人的肩膀上。

       特色二：语义从“隐含”到“显式”。传统STEP数据的语义隐含在EXPRESS模式文本中，只有读懂了模式文本的人才能理解数据的含义。SST通过EXPRESS到OWL的翻译，将这些语义显式化为机器可处理的逻辑公理。这意味着：机器不仅能“读取”数据，还能“理解”数据——理解类之间的继承关系、属性之间的约束、实例之间的逻辑关联。

       特色三：从“文件交换”到“知识网络”。传统STEP的范式是“文件交换”：一方导出文件，另一方导入文件，交换完成。SST的范式是“知识网络”：数据以RDF图的形式存在于网络中，任何授权的系统都可以实时查询、链接和验证。这种范式转变，使产品数据从“静态文档”变为“活的知识”。

       特色四：从“工具”到“平台”。传统STEP工具（如SDAI实现、STEP查看器）是面向特定任务的专用工具。SST是一个可扩展的平台：语义内核提供通用的数据管理和验证能力，上层可以构建各种领域应用。这种平台化思维，使SST具有更强的生命力和适应性。

       7.5 与STEP生态其他厂商的错位与互补

       评价一项数据技术的定位，最清晰的方式是将其放入同一生态中观察。在STEP技术生态中，有三类代表性厂商长期活跃，它们与SST的关系值得专门辨析。

       STEP Tools, Inc.（美国，steptools.com）是STEP语法工具链的代表。其旗舰产品ST-Developer是业界历史最悠久的STEP编程库之一，配套ST-Viewer可视化工具（可流畅渲染整车级装配模型）以及STEP/IFC文件验证工具。2026年夏季，该公司正准备发布第21版开发库，进一步改进STEP网格化算法与查看性能。STEP Tools的专长在于把STEP文件的读写、校验、可视化做到极致------这是"语法层"和"几何层"的精密工程。

       Eurostep（瑞典，1994 年成立，2023年起并入BAE Systems Digital Intelligence）是协同平台层的代表。其产品ShareAspace是一个贯穿全生命周期的工程数据枢纽，主打跨企业、跨供应链的安全数据共享与数字主线（Digital Thread）管理，客户名单包括 Airbus、Saab、Volvo、Renault、Scania、NASA、法国武器装备总局（DGA）等。ShareAspace底层大量采用STEP（尤其是 AP239/PLCS）作为交换格式，其新近发布的 1.9.x 版本持续强化复杂产品数据的跨组织流转能力。Eurostep解决的是"数据如何在企业间安全地流动"------这是流程与治理层的问题。

       Open CASCADE（OCCT，occt3d.com）是几何内核层的代表。OCCT自2000年起以开源形式发展，历经二十余年持续演进的开源几何内核，是全球大量CAD/CAM/CAE软件的几何底座，其数据交换模块（STEPControl）承担了无数应用中的STEP/IGES读写工作。OCCT解决的是"几何如何被精确建模与转换"------这是几何计算层的问题。

       三者的能力边界可以用一句话概括：OCCT让机器能"算出"形状，STEP Tools让机器能"读写并检查"STEP 文件，Eurostep让数据能"在组织间流转"------但它们都没有回答：当数据抵达接收方系统后，机器能否"理解"这段数据的业务含义？一个经OCCT转换、经STEP Tools校验、经ShareAspace交付的STEP文件，在目标系统中仍然只是几何与属性的集合；"这个孔是轴承座孔的基准面""这个零件在运维语义中属于可更换单元"这类知识，依然锁在人脑与文档之中。

       这正是SST的生态位：不与三者竞争，而是为三者所服务的整条数据链路补上缺失的语义层。一个可预见的协同图景是：OCCT负责几何读写，STEP Tools负责语法验证，SST负责语义建模与知识化管理，Eurostep类平台负责跨组织分发------四个层次各司其职，共同构成完整的工业数据基础设施。对技术决策者而言，SST的引入不需要替换任何现有投资，而是在既有工具链之上增加一个此前不存在的维度。

八、SST的应用场景与案例

       8.1 电气系统设计：SST-EDM与EWIS/AFNeT

       SST技术在电气工程领域的首个垂直应用是SST-EDM中的电气线束设计功能。电气系统设计，尤其是复杂产品（如飞机、汽车、船舶）中的电气线路互联系统（EWIS, Electrical Wiring Interconnection System），是数据管理难度极高的领域。

       EWIS涉及海量的电气元件（连接器、导线、继电器、断路器等）、复杂的连接拓扑（线束、分支、接地点）、严格的规则约束（电流容量、电压降、电磁兼容、防火等级）以及跨学科的设计协同（电气、机械、热管理、电磁仿真）。传统E-CAD工具虽然能绘制电气原理图和线束图，但它们管理的数据往往是“图纸导向”的——数据被封闭在专有格式中，难以与其他系统（如3DCAD、PDM、仿真工具）进行语义级交互。

       SST-EDM利用SST的语义能力，将电气设计数据从“图纸”提升为“知识模型”：

       ●每个电气元件不仅是图形符号，而是具有明确语义类型的OWL个体，携带完整的属性定义（额定电流、耐压等级、接触电阻、材料、制造商等）。

       ●每个连接关系不仅是线条，而是具有明确语义的对象属性，可以被查询、验证与关联。

       ●电气规则（如“同一回路的导线截面积必须满足电流容量要求”）可以被表达为约束规则，由验证引擎自动执行设计验证。

       ●电气数据可以与机械3D模型（STEP格式）在语义层关联，实现机电一体化设计的协同。

       本节涉及的六个界面视图——分解结构、产品族规格配置、线束拓扑、实例级数据组织、零件族管理与产品族配置（图8.1至图8.6）——可以清楚地说明"SST数据既可被人浏览、也可被机器理解"的含义。
       图8.1是SST-EDM的分解结构管理界面：以IEC 81346参考命名系统组织Portal洗车机的界面。左侧导航栏列出All、Breakdown Systems、General Parts、Product Families、Organizations、Class Systems、Templates、Person、Physical Individual、Document等模块；主视图区展示一个名为"GeneralPart"的分解系统实例—以Portal洗车机为顶层节点，向下逐级分解为吸井（Suction well）、Portal单元、侧风扇单元（左/右）等，每个节点均带有符合IEC 81346的参考代号（如=G1、=GPB1、=H1等）。
       图8.2展示了SST对产品族的规格化配置能力：SST用ProductClass（产品类）、SpecificationCategory（规格类别）与SpecificationItem（规格项）三个层次，描述一个具体产品配置及其全部特征；用户在界面上选定规格项后，系统可即时生成一份完整的产品规范（Product Specification）——不需要为每个变型单独建档。这正是STEP AP242的 ProductSpecificationAndConfiguration能力的语义化落地，也是管理十万级变型产品族（如图8.5的MIL-DTL-38999连接器族）的机制基础。

       右侧的Repository Statistics栏显示该仓库的规模：主数据库含183万条记录、派生索引103 万条、65个数据集、150个修订版本——直观呈现了语义网数据管理的工业级体量。

       在2025年10月AFNeT主办的EWIS Day上，LotharKlein展示了SST技术在EWIS领域的具体应用。

       1.统一数据模型：将电气系统的功能架构、逻辑连接、物理实现（线束拓扑）在统一的语义模型中关联，使设计人员能够在不同抽象层次之间自由导航。
       图8.3展示了EWIS线束的拓扑可视化：节点（N1–N6）与线缆段（S1–S7）构成的连接图。图中圆形节点分两类：N1–N6为连接点（连接器/端子），X1–X7为中间对象（如接头或过渡件）；带箭头的实线与虚线边（S1–S7及其子段S2-1、S2-2、S3-a等）表示线缆段及其走向，虚线表示途经中间对象的间接连接。界面顶部的主视图选项卡（Main、Property、Feature、Assembly Tree、Svg、EWH、Turtle）揭示了SST-EDM的"一数据多视图"特性：同一份RDF数据既可渲染为拓扑图，也可直接查看其Turtle源码——这正是"数据即本体实例"思想的界面化呈现。

       2.跨工具集成：SST的开放RDF接口，使SST-EDM能够与现有的3DCAD工具（如CATIA、NX）、仿真工具（如EMA3D、CST）和PDM系统进行数据交换，而无需依赖专有的点对点翻译器。

       3.设计规则自动化：将航空标准（如SAE ARP 4754A、DO-178C、DO-254）（SAE/Society of Automotive Engineers，国际自动机工程师学会； ARP/Aerospace Recommended Practice/宇航推荐惯例）中的设计要求和验证规则形式化为OWL约束和规则，实现自动化的设计合规性检查。

       4.变更影响分析：当某个电气参数（如负载电流）发生变更时，验证引擎可以自动追踪受影响的导线、连接器、保护装置，并评估是否需要调整线径或更换元件型号。
       图8.4表述了NamedGraph的导入层次与装配连接关系，是SST数据组织方式的最直观证据。黄色区域是各个NamedGraph（数据集）：HarnessDesign1是总装配图，通过 owl:imports 引入 ConnectorHousingABC（连接器壳体）、InsertXYZ（插芯）、FitRelationship_Slot1_Insert1（配合关系）等数据集；后者又各自引入TemplateSlot1、TemplateInsert1 等模板图；右侧的ConnectorFeaturesAA则承载通用接触特征定义及其配合关系（注意图中标注的"对称属性，任意方向成立"——这是OWL对称性的工程用法）。图中节点间的箭头是实例级的RDF三元组：Part通过lci:hasFeature关联PartContactFeature，SingleOccurrence通过sso:nextAssemblyOccurrenceUsage加入装配，两个 OccurrenceContactFeature之间通过AssemblyShapeJoint建立形位连接。这张图说明了 SST的核心主张：装配结构不是一张平表，而是一组通过owl:imports层层组合、可被机器逐层验证的语义图。
       图8.5以MIL-DTL-38999连接器族为例，展示SST-EDM对产品族（Product Family）的管理。左侧列表中，EPX、MIL-DTL-38999、MIL-C-39029、Series 77等条目都是产品族实例；选中MIL-DTL-38999（电连接器军标系列，现实中该族有十万级变型）后，界面右侧列出Base Type / Specific Type的规格层级（Series I/II/III 及具体型号）。这张图对应的能力是：SST用ProductClass、SpecificationCategory与SpecificationItem描述产品配置，可由用户按规格项动态生成一份完整的产品规范（Product Specification）—这正是STEP AP242的ProductSpecificationAndConfiguration能力的语义化落地。

       图8.6是官网公布的当前版本界面，与图8.5的演讲演示版相互印证：产品族（Product Family）以树状层级组织，每个族下按规格类别（Specification Category）与规格项（Specification Item）细分——图中可见连接器类产品按型号序列展开的配置结构。用户在界面上勾选规格项后，系统可即时生成一份完整的产品规范（Product Specification）。这正是STEP AP242的ProductSpecificationAndConfiguration能力的语义化落地：十万级变型的产品族不再需要为每个变型单独建档，而是"族 + 规格约束"的组合式定义——规格数据本身也作为RDF三元组存储，可以被查询、复用与版本追溯。

       8.2 文档与标准管理：非结构化对象进入同一语义框架

       工程数据管理不能只管理零件与结构，还必须管理随产品全生命周期产生的大量文档——标准、规范、图纸、报告。SST-EDM将文档（Document）作为一类主要对象纳入与零件相同的语义框架：任意数量的文档可登记进SST Repository，每个文档通过可定制的分类标识其种类（例如"国际标准"）；主文档（Main Document）之下可定义子文档与带版本的文档（Versioned Document），各类文档属性亦按可定制的属性集描述。文档对象与零件、分解结构一样，都是Repository中可查询、可版本化、可追溯的RDF资源------而非结构化文件本身则由Document Vault与RDF主数据协同存储。

       文档管理的四个界面细节见图8.7 a–d：
       图8.7a：文档登记与分类。EDM将文档列为与零件、模板等并列的主要对象类型；示例中登记的文档被分类为"International Standard（国际标准）"——关键在于，这个分类不是写死的枚举，而是用户可按企业需要定制的分类体系（可换成企业标准、工艺规范、检验报告等任意类别）。文档一旦挂上半定制化的语义分类，即可被精确检索，并成为规则约束的对象。
       图8.7b：主文档详情。展开一个文档对象，其标识、分类、描述等信息以结构化属性呈现——这些不是表单里的自由文本，而是 Repository中该文档IRI节点上的三元组，可以被查询，也可以被其他对象（如零件、分解节点）引用关联。
       图8.7c：主文档下的子文档与版本化文档结构。一个主文档（Main Document）可携带两类下级对象：子文档（表达内容上的从属或组成关系）与版本化文档（表达同一文档的演化谱系）；版本化结构复用SST的NamedGraph修订机制，一份标准的历次修订完整可追溯——这正是"文档对象与零件一样可版本化"的具体形态。
       图8.7d：文档对象的可定制属性。每个文档对象可挂接一组属性（编号、状态、责任人、日期等），且属性集合本身可定制——这与零件属性、分类系统遵循同一机制：属性取自上层本体已定义的词汇，而非各应用私造字段，从而保证跨模块、跨企业的语义一致性。

       8.3 PCB制造：从设计数据到制造指令的语义贯通

       印刷电路板（PCB）制造是另一个SST可以发挥重要作用的领域。PCB的设计数据（如Gerber文件、钻孔文件、IPC-2581格式）与制造执行系统（MES）之间的数据交换，长期以来依赖于格式转换和人工解释。

       SST可以在PCB设计数据的语义化方面提供以下支持：

       ●将IPC-2581（一种基于XML的PCB设计和制造数据交换标准）中的数据映射为RDF，与STEP格式的机械装配数据关联。

       ●建立PCB元件（元器件、焊盘、过孔、走线）的语义本体，使设计意图（如“这个过孔是散热孔”“这条走线是差分对”）能够被制造系统理解。

       ●将制造规则（如最小线宽、最小间距、阻抗控制要求）形式化为可验证的约束，自动验证设计数据的可制造性。

       ●支持从设计BOM到制造BOM的语义转换，自动处理替代料、工艺辅料等制造特有的信息。

       德中技术在其技术产品方案中，明确将PCB制造列为SST的重点应用领域之一。通过SST的语义数据管理能力，PCB制造企业可以打通从设计、工艺规划、生产执行到质量追溯的全流程数据链路，减少因数据理解偏差导致的制造缺陷。

       8.4 数字孪生与产品全生命周期数据集成

       数字孪生（Digital Twin）的核心理念是：为物理世界中的每个实体（产品、设备、产线、工厂）创建一个数字镜像，使数字镜像能够实时反映物理实体的状态，并支持预测、优化和决策。

       数字孪生的实现，需要解决一个根本性的数据问题：如何将来自不同生命周期阶段、不同系统、不同格式的数据，在统一的语义框架下关联起来？

       SST为这一问题提供了系统性的解决方案：

       ●设计阶段：CAD系统生成的STEP数据，通过SST翻译为语义化的RDF图，构成数字孪生的“设计基线”。

       ●制造阶段：MES系统的工艺参数、质量检测数据，通过RDF链接关联到设计基线中的对应零件和特征。

       ●运维阶段：物联网传感器采集的温度、振动、电流等实时数据，通过时间序列数据库与SST中的产品知识图谱关联，支持故障诊断和预测性维护。

       ●退役阶段：产品的维修历史、改装记录、材料成分信息，在SST的知识图谱中完整保留，支持回收处理和合规报告。

       通过SST，数字孪生不再是一个个孤立的数据模型，而是一个持续演化的、语义关联的知识网络。

       8.5 供应链协同与智能采购

       在复杂的供应链环境中，采购方和供应商之间经常面临“同名异义”和“异名同义”的问题。例如，采购方的物料编码“MTR-2025-001”和供应商的物料编码“SUP-A-456”可能指向同一个标准件，但两个系统之间没有自动的识别机制。

       SST可以通过以下方式改善供应链协同：

       ●建立基于开放标准的物料本体，将每个物料的规格、标准、认证、供应商等信息以语义化的方式表达。

       ●支持物料的“语义匹配”：不是基于编码的字符串匹配，而是基于属性（尺寸、材料、标准、性能参数）的逻辑相似性计算。

       ●将采购需求（如“需要一种抗拉强度大于500MPa的不锈钢螺栓”）表达为查询，自动在供应商数据库中检索符合条件的物料。

       ●支持供应链风险的语义关联分析：当某个原材料产地发生自然灾害时，沿供应链语义图关联查询受影响的全部产品。

       8.6 知识管理与设计复用

       工程设计是一个高度依赖知识复用的活动。一个经验丰富的工程师在设计新零件时，会自然地参考已有的类似设计、相关的标准规范、过往的成功案例和失败教训。但这种知识复用目前主要依赖于个人的经验和记忆，缺乏系统化的支持。

       SST可以通过构建“设计知识图谱”来支持系统化的知识复用：

       ●将企业历史设计项目中的产品数据（STEP模型）、设计文档、仿真报告、测试数据等，统一翻译为RDF图数据。

       ●建立设计知识的本体模型：包括设计问题（需要解决什么）、设计方案（如何解决）、设计原理（为什么这样解决）、设计约束（受什么限制）、设计评估（效果如何）等概念。

       ●支持基于语义的智能搜索：工程师可以用自然语言或结构化查询（如“寻找所有用于高温环境且重量小于1kg的散热器设计”）来检索相关知识，而不必知道这些知识存储在哪个文件、哪个系统中。

       ●支持设计推荐：基于当前设计任务的语义特征，自动推荐相关的历史设计、标准件、供应商和仿真方法。

九、前景展望

       9.1 技术演进方向

       SST作为一项融合传统工业标准与现代语义网技术的新型数据管理范式，其技术演进将沿着以下几个方向展开：

       方向一：与大型语言模型（LLM）的深度融合。2023年以来，以GPT系列为代表的大型语言模型展现了强大的自然语言理解和生成能力。将LLM与SST的知识图谱结合，有望实现“神经－符号”融合的智能应用：LLM负责自然语言的理解和生成，SST的知识图谱负责提供精确的结构化知识和验证能力。例如，工程师可以用自然语言询问“这个设计的散热方案有什么问题？”，LLM将问题解析为查询，SST执行查询并返回精确的结果，LLM再将结果组织为易读的自然语言回答。这种融合有望大大降低工程知识获取的门槛。

       方向二：实时语义数据流。当前的SST主要处理静态或准静态的产品数据（如设计模型、BOM）。未来的SST有望扩展到时序数据和流数据处理，支持物联网传感器数据、制造过程数据、设备状态数据的实时语义化。可以设想，这需要将RDF的静态图模型与流处理技术（如Apache Kafka、Flink）结合，实现“动态知识图谱”。

       方向三：分布式联邦知识图谱。随着供应链全球化和产业协同的深化，单一企业的数据仓库已无法满足需求。未来的SST有望支持跨企业、跨行业的分布式联邦知识图谱：每个参与方维护自己的SST数据节点，通过标准化的联邦查询协议进行协同查询，并可借助区块链等技术保证数据的可信与溯源。

       方向四：自主代理与智能合约。在SST的语义框架下，还可以设想构建能够理解产品数据语义的自主软件代理（Autonomous Agents）。这些代理可以在供应链中自动执行采购、质检、物流调度等任务，而智能合约（Smart Contracts）可以确保这些自动执行的过程符合预设的业务规则和合规要求。

       9.2 标准化与生态建设

       SST的长期成功，不仅取决于技术本身的先进性，还取决于标准化和生态建设。

       在技术先进性及其积累方面，SST的在线资源经历了清晰的演变轨迹。其中，早期的www.semanticstep.org（见图4.1） 是LKSoft与法国Nexter Systems的联合活动站点，记录了2006-2008年欧洲S-TEN研究项目（用ISO 15926-2概念与OWL处理STEP数据）及Oil & Gas、S3000L本体化等前期探索。随着2026年SST-Core v1.0.0与SST-EDM MVP发布，全部活动迁 www.semanticstep.com（见图4.2）。语义STEP完成了概念形成、项目实施、工程开发SemanticSTEP到今天完整的SemanticSTEP Technology技术体系的演变。
在标准化方面，SST社区需要推动以下工作：

       ●EXPRESS到OWL映射标准的完善：将当前SST实现的映射规则进一步标准化，形成ISO或W3C认可的技术规范，确保不同厂商的SST实现之间的互操作性。

       ●工业领域本体的共建：联合行业组织和龙头企业，共同开发和维护面向特定工业领域（如航空、汽车、能源、电子）的OWL本体库，避免本体的碎片化重复建设。

       ●与现有标准的协调：明确SST与ISO10303、ISO15926、IEC61970（CIM，电力系统通用信息模型）、IEC62714（Automation ML）等现有标准的关系，制定互操作指南。

       在生态建设方面，SST需要：

       ●培育开发者社区：提供完善的开发工具包（SDK）、文档、示例和培训，降低SST应用的开发门槛。

       ●建立行业联盟：联合工业软件厂商、制造企业、科研院所，形成SST技术联盟，共同推动技术落地和最佳实践分享。

       ●推动开源与商业的平衡：在核心语义内核层面考虑开源策略（如SST-Core已采用PolyForm非商用许可+商业许可的双重模式），以加速技术采用；在垂直应用领域保持商业创新动力，形成可持续的商业模式。

       9.3 对工业数字化转型的意义

       最后，让我们回到一个更宏观的视角：SST对工业数字化转型究竟意味着什么？

       工业数字化转型的核心挑战，不是缺乏数据，而是缺乏能够被机器理解、能够被系统共享、能够被知识驱动的数据。今天的企业拥有海量的CAD模型、仿真结果、生产记录、传感器数据，但这些数据大多以孤岛形式存在，格式各异，语义模糊。AI和大数据技术可以处理这些数据，但如果数据本身缺乏明确的语义，AI就只能做“统计关联”，而无法做“因果推理”和“知识发现”。

       SST的价值，在于它为工业数据提供了一套“语义基础设施”：

       ●它使工业数据从“哑数据”变为“活知识”。

       ●它使不同系统从“各说各话”变为“共享语义”。

       ●它使人工智能从“统计工具”变为“知识伙伴”。

       从这个意义上看，SST不仅是一项技术，更是一种工业数据管理范式的转变——从以文件为中心的交换范式，转向以知识为中心的网络范式。这一转变的完成，可能需要十年甚至更长时间，但它的方向是明确的：未来的工业数据，必将是语义化的、网络化的、可验证的。

       SST站在ISO10303（STEP）四十年积累和W3C语义网二十余年发展的交汇点上，承前启后，继往开来。它既是对传统工业数据标准的继承和发扬，也是对现代语义技术的工程化和落地。对于正在推进数字化转型的制造企业、对于正在探索下一代工业软件的技术团队、对于正在研究产品数据语义互操作的学术研究者，SST都提供了一个值得深入关注和积极参与的技术方向。

       9.4 现状与边界

       需要客观说明的是，SST仍处于发展的早期阶段：SST-EDM目前为MVP（最小可行产品），电气线束（EWIS）、3D 可视化、完整SHACL形状约束检查、跨仓库联合查询等能力尚在开发或规划之中；本体库（v1.0.1）对部分STEP部分的覆盖仍在持续扩展。本文所述的部分应用场景属于基于现有机制的能力外推。以开源本体（MIT）+ 双许可核心（商业/PolyForm非商用）的方式尽早发布，正是为了在真实工程反馈中迭代——这也是本文将"标准化与生态建设"列为与"技术演进"同等重要方向的原因。

十、结语

       本文从行业背景、历史脉络、技术原理、功能特色、应用场景和前景展望六个维度，对语义STEP技术（SST）进行了系统性的综述。回顾全文，我们可以提炼出以下几个核心观点：

       第一，工业数据的语义鸿沟是真实存在且日益加剧的。随着产品复杂度、系统异构性和协作网络化的不断提升，仅仅依靠语法层面的数据交换已无法满足工业协作的需求。语义互操作——即机器对数据含义的共享理解——已成为工业数字化转型的关键瓶颈。

       第二，STEP标准和语义网技术各自解决了问题的一部分，但都不够完整。STEP提供了精确的工业数据模型，但缺乏语义开放性；语义网提供了强大的语义表达和验证能力，但缺乏工业领域的深度积累。SST的价值在于将两者深度融合，取长补短。

       第三，SST不是对现有技术的替代，而是对现有技术的增强和扩展。它保留STEP的核心资产（EXPRESS模式、Part21数据），同时赋予其语义网的新能力（开放链接、逻辑验证、联邦查询）。企业不需要抛弃现有的STEP投资，而是可以通过SST逐步升级其数据管理能力。

       第四，SST的成功需要技术、标准和生态的协同推进。单一的技术创新不足以改变工业数据管理的格局，只有在开放标准的支撑下、在产业生态的协作中，SST才能真正发挥其潜力。

       SST的故事，本质上是工业界对“如何让机器理解产品”这一永恒问题的最新回答。从1980年代的IGES，到1990年代的STEP，再到2020年代的SST，每一代技术都在前一代的基础上迈进一步。IGES让机器能“看到”图形，STEP让机器能“读取”信息，SST让机器能“理解”知识。这一演进尚未结束，但方向已经清晰。我们有理由期待，在不久的将来，工程师与机器之间、机器与机器之间，将能够以共享的语义为基础，进行更深入、更智能、更高效的协作。

       免责声明：文中涉及的技术细节和产品信息，以各厂商最新发布的官方文档为准