传统架构开发VS PREEvision：一场效率与可靠性的降维打击

当前，整车功能数量激增，意味着需要更庞大的整车数据库、更复杂的硬件传感器与执行器网络、更密集的跨系统交互接口以及更难以预测的耦合效应。这样一来，单一功能的微小改动，可能会因复杂的依赖关系而引发意想不到的连锁反应，导致其他功能失效或系统不稳定。

传统的、相对线性的基于文档的开发和管理模式，正日益难以驾驭这种高度复杂、动态变化的“功能生态”，亟需全新的工具来重新定义功能的管理策略，避免功能堆砌带来的系统臃肿、可靠性下降和用户体验割裂。

今天我们来探讨一下基于文档的架构开发和基于工具（PREEvision）模型的架构开发之间的差异。

一、表达方式差异

• 基于文档开发：

自然语言描述、表格、示意图（通常是图片形式）来表达；信息分散在不同文档中，理解依赖人工解读，易产生歧义。

• 基于PREEEvision开发：

所有设计元素（需求、功能、软件组件、硬件组件、接口、信号、总线通信、拓扑结构、线束、诊断等）在统一的、形式化定义的模型中创建和管理。模型元素具有明确的语义、属性、关系和约束。

二、设计流程

• 基于文档开发 ：

线性瀑布式开发，阶段间依赖文档评审和手工传递，需求变更或设计调整需要手动更新大量相关文档，易出错、效率低、耗时长，并且设计信息在不同团队（系统、软件、硬件、测试）间通过文档传递，易丢失或误解。

• 基于PREEEvision开发 ：

模型作为“单一数据源”，贯穿整个V流程。需求可链接到模型元素，设计在模型中演进，软件可部分自动生成，测试用例可基于模型生成。 模型是协作的基础平台，不同团队在同一个模型的不同视图上工作。模型可导出或自动生成下游开发所需的数据。

三、完整性

• 基于文档开发 ：

不同文档间、文档与实现间的一致性高度依赖人工检查和维护，极易出现错误、遗漏、过时信息（如：接口改了，但相关文档没更新）。检查所有文档是否覆盖所有需求、所有接口是否定义完整也是非常困难的。如下图，如果IGN相关信息改变，一个文档就有228处有关IGN的信息需要修改，更何况整车文档，纯手工维护不太现实。

• 基于PREEEvision开发 ：

模型数据唯一，便于统一修改更新，如下图：

PREEvision自动维护模型内数据之间的一致性。模型元素间的链接关系确保可追溯性。工具可进行模型规则检查、接口一致性检查、需求覆盖度分析等，自动化程度高，更易发现设计缺陷。

四、验证确认

• 基于文档开发 ：

验证主要在物理样机或硬件在环阶段进行，依赖实物测试。设计缺陷发现晚，修改成本高昂。基于静态文档难以进行有意义的早期系统级仿真。

• 基于PREEEvision开发 ：

可在模型层面进行功能仿真、架构权衡分析（性能、成本、功耗）、网络通信仿真（如CAN/LIN/Ethernet）。在物理实现前发现并解决问题。

五、重用性

• 基于文档开发 ：

设计知识固化在文档中，难以被有效检索和复用（尤其是跨项目），高度依赖个人经验和文档解读。

• 基于PREEEvision开发 ：

功能组件、子系统、接口定义等可作为标准化模块存储在库中，方便在新项目中快速重用。模型本身就是结构化的、可执行的设计知识库，易于管理和传承。

总结：

特征	基于文档开发	基于PREEvision开发
核心载体	静态文档 (Word, Excel, PDF, Visio图)	数据库模型
信息表达	自然语言、表格、静态图片，易歧义	结构化元素、明确语义、可视化关系图
流程/迭代	线性瀑布为主，迭代困难，变更成本高	支持敏捷迭代，变更影响可控，效率高
协作基础	文档传递，易丢失信息	单一模型源，多视图协作
一致性维护	手动，极易出错	工具自动维护
完整性检查	困难，依赖人工	工具自动化检查
仿真验证	困难，主要在后期实物测试	模型在环/软件在环仿真
自动化程度	低 (文档编写、传递、检查、代码/测试生成均手动)	高 (可定制化开发)
重用性	差	好 (模块化库管理)
知识管理	分散，依赖个人	集中、结构化、资产化
管理复杂度	力不从心	核心优势（EEA管理及开发）
行业趋势	逐渐被取代	现代EEA开发的主流和未来方向

基于PREEvision的开发是应对现代汽车电子电气架构日益增长的复杂性、安全性要求、开发效率压力和创新速度需求的必然选择。它通过统一的、形式化的、可执行的模型作为开发和协作的核心，极大地提升了设计质量、一致性、重用性、验证效率和变更管理能力，显著降低了后期修改风险和开发成本。虽然向MBD转型需要投入（工具、培训、流程变革），但其带来的长期收益是巨大的，已成为行业主流和发展方向。基于文档的开发方式在简单系统或特定环节仍有应用，但在整车EEA层面已被MBD全面超越。