合作伙伴资讯｜从手动画图到自然语言建模：TSMaster迈向AI原生MBD

手工逐块绘制模型，正在退出汽车电子基于模型设计（MBD）的中心环节。近日，上海同星智能科技有限公司升级 TSMaster AI 自动建模能力。工程师用自然语言写清控制对象、接口、边界条件和验收标准，智能体随即起草候选逻辑；TSMaster MBD 工具检查逻辑、生成可见模型、运行预定义工况，并留下模型级验证证据。

这次升级改写了建模分工。拖入模块、连接端口、整理布局和同步需求等重复操作交给智能体和工具，工程师把精力放回控制意图、风险边界和验收标准。AI 先交候选逻辑，TSMaster 再生成模型，并用规则和实际输出把错误拦下来。汽车电子 MBD 的入口由此变成自然语言，出口变成可复查的验证证据；中间的建模与模型级验证交给工具执行，工程师守住意图、风险和最终验收。

需求被多次翻译，是控制开发中最容易被忽略的问题。电动车窗防夹常被简写为“上行遇障后立即反向”，正式需求还写明 6 路输入、4 路输出、状态结构、10 ms 周期、8.0 A 阈值、50 个周期时限、竞争条件、复位规则和十一项验收工况。这些工程事实与判据由工程师定义，智能体负责结构化表达，缺失内容不能凭空补齐。

工程师仍要把需求解释成可执行规则。高电流和上端点信号在同一个采样点出现时，控制器应按车窗到顶处理并停止上行驱动，还是按防夹触发处理并立即反向？反向动作结束后，防夹锁存是否解除？锁存期间收到新的上行请求，控制器应响应还是拒绝？规则没有写清的部分，会被需求、模型、代码和测试分别补全，最后形成四套看似合理的执行含义。

模型阶段发现分歧，团队只需处理一个条件、一项状态或一条判据；等到台架联调才暴露，排查范围会同时覆盖需求、模型、代码、信号映射和测试环境。控制意图的澄清与验证必须走在代码生成前面，后续环节才能围绕同一份意图工作。

TSMaster AI 建模接收的是完整自然语言工程需求。智能体把已定义的接口、状态、参数、工况和判据整理为候选控制逻辑，工具检查并生成模型，工程师最终面对画布、状态结构、运行轨迹和结果。系统内部的形式化表达留在工具链中处理。

评审也随之改变。输入、状态、边界和期望输出从起点进入同一个可运行对象。团队直接检查规则是否进入模型、是否被工况触发、实际输出是否满足判据。需求变更时，受影响的状态、接口和测试都有清晰入口。

智能体通过一套标准工程工具连接机制，调用 TSMaster 中真实的建模与仿真能力。它根据工程师给出的接口、状态、转移条件、动作和优先级形成候选控制逻辑。系统用可解析的形式化表达承接这份候选，后续检查、模型生成和仿真都围绕它执行；工具状态、模型身份和运行结果返回同一任务，供智能体安排下一步。

候选控制逻辑通过解析、名称、类型和语义门禁后，才成为系统内部的规范意图。TSMaster 根据规范意图创建模块、端口、状态和连接关系，并把结果投影到可见画布。用户不需要读内部表达，也不用亲手处理坐标和连线；工程师面对模型结构、运行轨迹和工况结果，直接判断智能体是否准确理解了原始需求。

图1.工程师提交的自然语言需求与AI自动生成的TSMaster Block Diagram

需求由此变成模型：工程师定义意图和判据，智能体起草候选逻辑，TSMaster 逐项检查并生成画布。随后，智能体再把预定义输入送入模型，回收实际输出，模型转入行为验证。

AI 会编造不存在的信号，混用数据类型，漏掉状态出口，写出相互冲突的条件，也会生成语法上无法解析的内容。受控样本中的首版候选逻辑就没有通过检查，工具返回明确诊断。智能体读取诊断、修改内容、重新提交。任何一道形式化门禁失败，流程都会停下并把问题交回智能体。AI 可以连续修正，却无权跳过检查。

形式化门禁全部通过，只能说明候选意图具备完整结构。模型运行后还可能暴露另一类错误：状态切换与原始需求不符，边界工况下输出错误，时间条件提前或延后，预期锁存没有保持。TSMaster 将实际输出与工程师预先定义的判据逐项比较。行为一旦偏离需求，结果再次打回智能体，智能体修改意图、重新生成模型、重新运行工况。

两类门禁处理的错误不同。形式化门禁检查候选意图能否被严格解析，引用的信号和状态是否存在，类型与关系能否闭合；行为门禁运行生成后的模型，把每个采样点的实际输出与原始需求中的期望值比较。前者拦住“模型根本无法成立”，后者拦住“模型能跑但跑错了”。诊断位置、错误原因和第一处不一致都会返回智能体，下一轮修改因此有明确目标。

循环持续到形式化门禁和模型行为门禁全部通过。错误无法消除时，流程停在当前阶段。工具不会替 AI 遮掩幻觉，也不接受“已经完成”作为结果。智能体不能用文字解释覆盖工具结果，缺失证据的输出也不能标记为完成。每轮迭代都要以新证据结束。

模型生成后，TSMaster 立即进入行为验证。系统在代码生成之前运行模型，用独立定义的输入工况和期望输出核对控制行为。控制模型回答“系统应怎样工作”，测试向量和判据回答“怎样证明它按预期工作”。两者相互独立，模型无法用自身逻辑证明自身正确，每一次运行都会留下可复查的输入、输出和结论。

工程师为电动车窗受控样本预先定义十一项模型级工况，覆盖正常动作、请求冲突、端点与高电流竞争、防夹反向、时间边界、提前结束、复位和锁存抑制。十一项工况围绕图 2 中的状态转移和并行安全监测展开，模型实际运行后，输出均与预设判据一致。

图2.AI根据同一需求自动生成的TSMaster AiFlow状态机

受控样本的每项工况都保存输入、实际输出和比对结果。模型在给定条件下做了什么，决定该项工况能否通过。智能体的完成声明和模型文件的存在都不能代替运行证据。出现偏差时，团队直接修改对应的需求、状态、接口或判据，再重新运行受影响的工况。代码生成接收一份已经被运行和质疑过的模型设计。

在代码生成之前，完成模型层应完成的验证；在每一层，完成该层应回答的验证。模型级运行先检查控制意图与边界，生成代码后再由软件在环确认代码没有改变模型意图，由处理器在环检查目标工具链、数值与资源，由硬件在环、台架、系统和整车继续验证控制器、通信、真实部件和运行环境。后一层从同一套规则、工况和判据出发，逐步加入更真实的目标与环境。

AI 原生 MBD 围绕同一份规范意图组织交付：可见模型、代码生成输入、测试工况、运行结果、变更记录和工程文档彼此关联。需求发生变化时，智能体定位受影响的状态、接口和工况，重新组织模型与回归；工程师依据新一轮证据判断变化是否正确实现，无须重新比对多份彼此分离的材料。

沿着这条路线，同一份意图继续组织后续制品。模型用于审查和仿真，经过验证的模型语义作为代码生成输入，既有工况和判据进入软件、处理器与台架层的测试设计，执行记录再沉淀为报告和追溯文档。各层在对应目标和环境中形成自己的结论，并沿用同一套规则。智能体最终交付模型、代码、测试、文档和证据之间能够相互解释的关系。

TSMaster 本来就是汽车电子工程平台。总线、诊断、标定、测量、脚本和自动化测试能力已经服务于开发现场，MBD 让控制模型进入同一工程。模型输入输出可以按当前支持范围接入系统变量、车辆网络信号、测试控制和测量对象；模型阶段定义的观察量和判据，也可以成为后续联调、问题定位与回归设计的起点。

不同角色可以围绕同一工程对象协作。系统工程师确认需求边界，建模人员审查状态和接口，测试人员设计工况和判据，测量人员观察同一组信号。所有人共同检查模型做了什么、证据说明了什么、下一步还需要验证什么，同一条控制要求不再被每个环节重新翻译。

在当前支持范围内，已有模型、数据字典和可承接组件可以逐步进入 TSMaster 的建模、仿真和验证链；新建模型则可以从一开始就把需求、模型、工况和判据组织在同一工程中。迁移和新建都服务于同一目标：防止模型、代码、测试和文档在持续迭代中形成彼此无法解释的孤岛。

人类继续负责汽车电子研发中的目标、风险和验收，手工逐块绘制模型将逐步退出流程中心。智能体负责模型构建、工具调用和证据整理，TSMaster让每个步骤可检查、可运行、可回看。AI先给出候选答案，工程链再把答案变成能够接受验收的完整对象。问题在代码生成前被发现，后续代码、测试和实物验证便拥有同一份可信起点。AI原生MBD由此跨过“自动画图”，进入自动执行与工程验收。