IBM：从架构设计到Autosar的具体工程实践

一般而言，架构设计会涉及到很多循环迭代，是一个循序渐进的过程。2023年5月9日-10日，在2023捷途汽车电子架构与智能驾驶论坛上，IBM大中华区科技事业部ELM解决方案华南区总监彭俊表示，在系统工程中，IBMRhapsody借助Harmony方法论和打通架构到Autosar的全套功能，从而减轻工程师们的工作量，降低工作负荷，提高工作效率，让工程师聚焦在架构设计的核心上。

彭俊表示，架构设计首先要做需求建模，需求是分层级的；模型创建后可搭建活动视图；再到逻辑架构阶段，可根据架构设计的理念进行内容切换。对此，IBM在用例建模、场景分析、活动视图等过程进行了实践。

IBM大中华区科技事业部ELM解决方案华南区总监

以下为演讲内容整理:

数字化研发有三个步骤:第一个是质量和效率的提升；第二个是正向设计，通过正向设计的方式做更多面向创新、面向整车的内容，正向设计的内容需要借助MBSE的能力；第三个是AI，借助AI的能力将架构设计、产品、服务更快地、更好地推向市场。

今天我们将重点讲第二个层面，从需求出发到架构设计，到架构的实际应用，再到具体的、底层的内容一套完整的过程。

架构设计到功能实践的工作流程

以下是IBM的Harmony方法论到Autosar全过程的图示。总的来说，先进行需求分解，通过IBM自动化的功能分析确保所有的系统功能得到正确的、自动化的分解，分解后将架构分成两部分，一个根据性能和选型要求，以及具体的实践技术要求进行技术架构的分解；另一个进行架构的可选工作，用什么样的架构？什么样的架构满足当下的产品要求？完成架构的可选工作后，接下来进行结构化的设计，将操作和功能分配到对应结构。

图源:IBM

一般而言，架构设计会涉及到很多循环、迭代，会有很多调试、演进的过程。同时，从功能到逻辑，再到具体设计的部分，如何将系统功能变成中立的、抽象的逻辑结构，不依赖于具体特定的技术，实现需求，对后续的软硬件解耦、开发以及接口到端口的定义都大有裨益。

从系统工程来讲，我们希望通过更加优秀的架构设计、逻辑结构设计，来减轻因需求变化而带来的架构变化调整。前面已经有系统的功能设计、功能分析、逻辑结构设计、架构设计，经过一系列的迭代、循环，逐渐将其变成一个可执行到可开发阶段的架构。通过该架构，可以直接把接口、端口等直接定义成Autosar模型，减轻架构设计师的工作量。

基于整体架构展开具体工作，下图是具体的功能实践。

图源:IBM

首先是功能分析，上述提到功能分析要先做需求建模，需求建模要确保所有需求都在用例模型中，从原始需求到产品需求，到子系统、零部件、软硬件需求等，需求是分层级的，所以此处的需求是个概称，涵盖所有的内容。创建模型后，我们会对用例图进行自动分解，划分其活动图，将其用例中的所有内容、参与者、要求变成活动场景，我们称之为活动视图。有了活动视图后，可以通过活动视图计算功能的工作流，观察每个活动路径的具体场景怎样，会发生什么，再通过序列图表达出来。

接下来是逻辑架构。识别了系统的逻辑运行的结构体、边界，以及相应的内容，我们就可以将各种功能分配到对应的逻辑结构上，对具体的操作步骤进行切片划分，比如为了解耦、为了分布式部署进行特定划分。就工程活动而言，只需要进行切片，并拖拽相应功能到对应内容进行切换，我们就能得到一个场景的序列图；基于场景的序列图，可以将行为放到子系统中，子系统会形成所需要的端口和接口。

再到物理和软硬件架构。从架构设计角度来讲，物理和软硬件架构与逻辑架构的操作步骤相同，也要先做架构对象的图示，通过活动图切片、结构体划分，产生对应的结构以及端口、接口等，然后形成状态活动，并通过系统反过来进行仿真，去核对设计过程、架构想法、分解过程是否可行，相应的内容是否OK。通过系统的仿真反复验证后，再进行二次调整，最终目的是到Autosar这个内容可以进行具体设计决策。将做好的类图或结构图，通过Autosar定义转化到Autosar模型，定义的过程是工程师操作的过程，但定义后，是M to M的转化引擎，实现Autosar模型的转换，并可以直接使用Autosar模型。Autosar模型转化后，会到物理结构模型，系统导出产品，给到下游，完成后续工作。

从架构设计到架构分解、选型、逻辑结构、软硬件结构，最后到Autosar模型，再到文件导出，整个流程相当于将原本需要系统工程师、软硬件工程师参与协同的工作，在大的流程中都做完了。

基于工作流程，IBM的具体实践

第一步用例建模，例如，有个车辆开门的动作，然后是开门后亮灯的动作。活动是控制灯的开关，涉及门和灯两个实体，这是一个很简单的用例图。我们通过工具进行场景分析后，在建模过程中，工具会自动生成内外接口的相应功能、参数等，分析结果会直接反馈成模型图形。

图源:IBM

基于模型图形，再建立活动图。用例的活动图会定义开门的动作，有个开门的时间，门开了，对灯打开或关闭进行简单的控制，涉及到的对象包括门、灯、控制活动等。通过这个部分，我们会直接看到相应的模型内容以及接口要求，可直接创建序列过程、活动过程，这个过程原来需要手工绘制，现在是use-case完成序列图的自动创建，再去创建测试工作台。

创建序列图后，点击模拟运行。此时还没有任何代码，只是一个初步的开门后开灯、关灯的想法，接下来的所有工作都由系统自动完成。我们会启动测试工作台，通过测试工作台创建一个可以运行和模拟仿真的环境，一步一步的调用观察当前在哪个活动，对哪个元素进行工作，以及它会达到怎样的效果，自动的去绘制事件以及事件活动等一系列动作，并对其分支进行处理，还可以加分支条件的判断，多做一些看板和按纽，对整个过程进行控制。

图源:IBM

通过一系列的活动，我们能从最开始对架构进行仿真，确保后续逻辑分析工作不会有遗漏、不会有错误等，最后通过功能把它保存下来，形成完整的新序列图作为后续活动的参考。

工程师做完功能分析后，开始做逻辑结构设计，逻辑结构图中划分各个功能对应的各个部分。通过对活动视图增加结构划分，讲不同的活动分配给不同的结构实体。具体实践上来说，在活动图增加了两个框结构，一个是车身控制，一个是灯的开关控制。这两个控制系统可以控制将一些功能放在车身上还是灯的开关上，两种不同的调整取决于架构设计的理念、解耦或其他原因，但在此，工程师只需要对具体的内容进行拖拽，拖拽完成后，系统会自动通过甬道图的切片，自动在模型上对功能进行划分，并建立相应的接口、函数、方法，以及后续对应的能力。

图源:IBM

序列图的过程是自动产生的，产生后，我们可以到下一级，每一层函数的颗粒度会继续向下分解，每一层会进行循环迭代，基于前面的内容生成内部端口、外部端口、接口等，整个图形的内容都是系统自动画出来的，并且会自动划分，划分依据参照架构设计，包括功能的划分，结构体的划分，接口的划分等。

视频无法在word里面展现，所以借助下图的一个仿真示例，来查看Rhapsody如何做活动图，如何做仿真，系统如何一步一步实时执行，并且这个过程是可以实时控制，以便让工程师查看系统在运行状态下的各种设计情况，包括结构、接口、方法、参数等等内容是否合理是否有优化空间等。并且通过一直调整、优化、再仿真这样一个循环迭代的过程，让工程师聚焦在架构设计上。

图源:IBM

接下来Autosar会进行下一步工作。通过定义调整对象的内容，我们可以决定架构模型中哪些内容需要进入Autosar模型。模型生成后，还可以导出Autosar文件。从一开始开门、开灯、关门等一系列简单的用例，到最后Autosar文件的产生，就是整个的功能实践。

通过Rhapsody的setstereotype的功能，讲架构设计元素定义为Autosar的元素，并且后续通过M2M工具引擎，直接无缝转化架构设计模型到Autosar模型，不仅衔接了架构设计和Autosar模型设计，同时也大量减轻了工程师映射和匹配两者的工作量。

图源:IBM

图源:IBM

图源:IBM

通过M2M转化后的Autosar模型，后续架构模型优化、调整后，再次转化Autosar的模型，并且通过Rhapsody的模型比较、合并的功能，可以直接更新Autosar的模型，这样避免了模型调整、变更给工程师带来的额外工作。

IBM ELM全生命周期管理

前面我们做了很多关门、开门的模型，这个模型会同步到IBM ELM全生命周期管理软件中，我们可以对标或查看需求模型是什么样子，将有利于全生命周期内的管理，我们的模型不再是孤立的，而是可以直接同步到ELM平台。

图源:IBM

整个ELM平台，比如做汽车仿真，我们可以放入更复杂、更多汽车环境的情况，观察汽车电路运行。因为我的架构设计从一开始就对它进行了仿真，所以能够减轻后续返工的成本，规避掉一些错误、干涉、冲突，或遗漏等情况，把模型作为企业资产保留下来。并且这个模型易于查看，架构模型一层一层按照这个方法做完后也能够保留下来。

整体上来说，架构设计是正向设计的关键和核心，不仅需要让企业知其然也要知其所以然，同时，架构设计对资源的要求非常高，不仅仅是资源本身的要求，同时对资源的安排和配置也要合理利用，避免资源的无效安排从而造成浪费。并且架构设计成果也是核心智慧资产，也需要有效的管理和继承和重用，通过IBMHarmony方法论和 Rhapsody架构设计工具，不仅仅减轻了工程师的工作负荷，让工程师聚焦在更关键的架构设计上，更加缩短了工程师在非架构设计工作的工作时间，同时还提高了资源的配置和利用能力，并且将模型这种核心资产进行了有效的管理，为组织学习和重用奠定了强大的基础，进一步提升企业的核心竞争力。