AUTOSAR 是软件架构在汽车行业的特殊应用，其“在标准上开放，在实施上竞争”的理念推动了流程的专业化分工，形成了成熟的开发工具链。Simulink 的 AUTOSAR Blockset 是 AUTOSAR 应用层软件开发的主流工具，与 System Composer 的结合支持 AUTOSAR 软件组合（Software Composition）的开发，进一步完善了 AUTOSAR 的正向开发流程。
在功能安全标准 ISO 26262 和过程能力改进及成熟度评估规范 A-SPICE 中均提出了类似的需求-架构-设计-实现的正向开发流程， Simulink 以其强大的图形化建模和高效的自动代码生成功能深刻地影响了复杂系统的软件设计和实现模式，
本文通过案例来展示这一过程，希望为汽车行业的软件开发用户提供参考，也相信从事其他行业复杂系统设计的用户也能受益。
应用案例
我们以简化的安全带警示系统作为案例，有驾驶经验的用户应该熟悉基本工作原理：在行驶状态下如果系统检测到驾驶员未系安全带应该发出声光提示。系统输入包括点火钥匙信号、安全带状态信号和原始车速信号，系统输出为安全带警示灯驱动信号。原始车速信号通常需要经过滤波后才能作为控制信号使用。
设计思路
上述系统的软件功能以软件组合的形式表征，包含了两个软件组件：车速滤波 SWC 和警示逻辑 SWC，车速滤波 SWC 将原始车速信号进行低通滤波后的车速信号传递给警示逻辑 SWC 使用。系统的输入输出信号和 SWC 的传递信号封装为两组总线类型：传感信号总线和控制信号总线。接口设计和组件划分如下：
在这里接口和组件输入输出分别代表了 AUTOSAR 中的 Interface (相当于数据类型)和 Port (相当于数据实体)的概念。以上设计思路进一步整理后形成规范化的设计文档，作为 Simulink 平台设计环节的起点，开展后续需求创建、架构设计、详细设计、设计验证和代码生成等工作。
需求创建
需求可以从以上的设计文档导入或直接在 Simulink 需求编辑器中创建，以对照进行架构设计和详细设计并建立起相应的链接关系，为以后的需求追溯和变更管理做准备。
架构设计
架构设计相对于详细设计应有较高级别的抽象，接口控制文档（ICD）或架构模型为其主要输出内容。在 Simulink 的启动页的 AUTOSAR Blockset 下打开软件架构模板即进入 AUTOSAR 软件组合架构的设计页面。
在菜单栏的 Design Tools 下打开 Bus Editor 定义总线类型，这一步对应 AUTOSAR 的接口定义(如有需要可在 Simulink 数据词典或工作空间中预先定义所需 AUTOSAR 数据类型)。
对照需求创建架构组件和输入输出端口，端口的数据类型从上一步定义的接口类型中选择，组件类型的选择为按 AUTOSAR 标准定义的应用组件、传感驱动组件、复杂驱动组件等预定义类型。
详细设计
架构创建完成并确认后，可以从架构组件关联已有的 Simulink 设计模型或直接创建新的设计模型。设计模型以自动继承架构模型端口的方式实现了接口控制，并自动创建 AUTOSAR 属性词典及其与 Simulink 的映射。
默认情况下端口的所有元素都会生成，设计时可以根据算法需要删减。车速滤波 SWC 和警示逻辑 SWC 的算法设计分别如下：
设计验证
符合功能安全要求的设计验证环节比较复杂，在此不再详述。就本例软件组合的功能测试而言，组合架构模型可以使用 Simulink Test 的 Test Harness 生成功能自动生成包括测试输入、测试评价、调度机制等在内的测试环境进行系统功能测试；也可以将组合架构模型以模型引用的形式插入到其他已有的测试环境中。
代码生成
设计验证通过后，可以从软件组合直接生成 AUTOSAR 代码和 ARXML 接口描述文件。从 ARXML 文件架构中可以看到数据类型和接口类型等共用元素在组合级统一生成。
总结
以上主要介绍了 System Composer 和 AUTOSAR Blockset 对 AUTOSAR 正向开发过程的支持，此外架构模型对Client-Server模式、基础软件集成仿真等功能限于篇幅不再赘述，有兴趣的读者参考最新版本的帮助文档。需要说明的是，System Composer 同样适用于 AUTOSAR 之外的通用架构设计，应用流程与之类似。
