如今，道路上的汽车数量比以往任何时候都多，汽车行业正不断发展和调整，以满足新技术的需求。为了更好地进行复杂性管理、缩短工程时间并降低成本，汽车开放系统架构（AUTOSAR）应运而生，其目标是实现电子控制单元（ECU）的标准化。

目前，AUTOSAR标准已应用于汽车行业，本文旨在研究该标准是否可用于与汽车行业无直接关联的领域。

01. 简介

1.1 项目

ARCCORE希望研究经典AUTOSAR（Classic AUTOSAR）是否可用于以可视化方式展示来自网络的数据或传感器数据。在本项目中，从上述任一类型数据源收集到的信息，将以字母和/或数字的形式显示在一组LED灯条上，并根据输入数据进行相应调整。这一任务由电子控制单元（ECU）完成，ECU负责处理输入数据，并对数据进行转换，以便在LED上显示。输入数据可通过相应的API从个人计算机（PC）、互联网或传感器收集，随后通过CAN连接直接传输至ECU。

1.2 目的

AUTOSAR由一群对汽车领域感兴趣的合作伙伴联合设计开发，其主要创建目的是为汽车行业建立一个开放且标准化的软件架构。本文的目的是研究AUTOSAR在汽车行业之外的领域应用效果如何。

1.2.1 研究问题

本项目重点围绕以下两个研究问题展开：

·  在与汽车行业无直接关联的设备上，是否能够实施AUTOSAR标准？

·  在与汽车行业无直接关联的系统中，AUTOSAR的运行表现如何？

1.2.2 范围界定

本项目原本可进一步扩展为采用自适应AUTOSAR（Adaptive AUTOSAR）的信息娱乐显示屏。信息娱乐系统可通过提供实时数据，帮助消费者了解车辆的各项功能，还可提供如今智能手机上常见的高端功能。然而，采用自适应AUTOSAR实现这一目标需要大量时间，因此可在未来无时间限制的情况下进一步开发。基于此，本项目将范围限定为仅使用经典AUTOSAR（Classic AUTOSAR）。

1.3 需求

本项目最初的计划是利用传感器读取物理运动部件的输入数据，例如设计一个用于统计道路车辆数量的系统，然后在LED面板上显示相关信息。由于传感器相关功能仅为一个可在时间充裕时实现的想法，因此被列为最低优先级需求。

1.3.1 需求清单

需求清单中的需求按优先级分为不同级别，其中高优先级需求是项目执行期间必须完成的内容。

·  高优先级：绿色

·  中优先级：橙色

·  低优先级：红色

具体需求如下：

·  ECU必须按照AUTOSAR标准进行编程。

·  ECU必须能够无故障、无崩溃地运行。

·  系统应易于根据所需采集的数据类型进行调整。

·  具备一个静态数据集，该数据集可由ECU轻松转换为可视化数据。

·  LED需根据输入数据进行更新。

·  ECU可通过CAN总线从PC接收实时数据集。

·  ECU必须通过以太网电缆接收实时数据集。

·  通过ECU上的数字输入/输出（Digital I/O）控制LED。

·  使用物理运动部件（如传感器）来模拟实时数据集。

各项需求的验证方式如图1.3.1.1所示，该图表还展示了验证的先后顺序。ECU编码验证应作为一个过程，贯穿整个项目始终。

图1.3.1.1：展示各项需求的验证方式。“验证对象”列指明需验证的部分；“验证方法”列说明验证的实施方式；“预期结果”列描述验证应达到的预期效果

1.4 工作分配

本项目采用 极限编程 （XP）方法，核心是两人一组进行编程工作，大部分任务都需以小组形式完成。不过，也存在部分分工情况，例如一人在焊接工位处理LED焊接工作时，另一人负责撰写报告。由于项目中的大部分任务都需要两人共同讨论确定实施方式，因此我们决定不进行过多的任务拆分。

总体而言，工作分配相对均衡。如果某一天一人主要负责编程，另一人负责查看代码编写并提出意见，那么第二天两人会互换角色，由前一天查看代码的人负责编程，前一天编程的人负责查看代码并提出意见。

02. AUTOSAR及相关组件

本章将介绍AUTOSAR的定义，阐释AUTOSAR的基础架构、电子控制单元（ECU），最后说明CAN通信帧的相关知识。

ECU和CAN是汽车行业中用于执行特定任务和实现通信的典型组件，如图2.1所示，本项目同样使用了这些组件。

图2.1：汽车俯视示意图，展示了汽车内部采用ECU和CAN总线的结构示例，包含右前指示灯、左前指示灯、警示灯开关、指示灯开关、左前指示灯ECU、中央车身ECU等部件

2.1 AUTOSAR定义

AUTOSAR是汽车行业内的一项标准化技术。2002年8月，宝马（BMW）、博世（ Bosch ）、大陆集团（Continental）、 戴姆勒-克莱斯勒 （Daimler Chrysler）、大众（Volkswagen）联合成立了启动团队，并展开初步讨论，不久后西门子威迪欧（Siemens VDO）也加入其中。

如今，AUTOSAR的核心合作伙伴包括宝马集团（BMW Group）、博世（Bosch）、大陆集团（ Continental ）、戴姆勒（Daimler）、福特（Ford）、通用汽车（General Motors）、标致雪铁龙集团（PSA Group）、丰田（Toyota）、大众集团（Volkswagen Group）。

该标准规定了电子控制单元（ECU）软件的参考架构。

2.2 ECU定义

如今的现代汽车对电子控制的依赖程度越来越高，电子组件被集成到模块中，这些模块在电气、机械和化学环境方面都有特定要求。早在20世纪70年代，电子控制技术就已进入汽车行业。

高端汽车中ECU的数量正不断增加，如今部分汽车配备的ECU数量已多达120个，在某些情况下甚至更多。

2.2.1 ECU功能

汽车行业的发展日新月异，ECU的数量也随着汽车技术的发展而不断增加。对于自动驾驶模式而言，汽车需要具备多种功能，电子控制单元（ECU）便是其中之一。

大量ECU的应用会导致通信开销增加，这种通信开销主要体现为局域网内的消息交互，而网络中的所有节点均充当认证服务器的角色 。

ECU用于从各类传感器收集数据，并控制汽车的多种功能，包括动力传动系统、娱乐系统、制动系统、动力转向系统和照明系统等。为确保系统正常运行，需使用不同的总线网络，其CAN总线和 FlexRay总线 对于高速网络至关重要。此外，还需要网关ECU实现不同总线之间的数据读写及协议转换。

2.2.2 工作流程

AUTOSAR方法学（如图2.4.1所示）详细说明了如何为ECU生成可执行代码，其工作产品流程以XML文件形式存储。该方法学包含系统视图（System View）、ECU视图（ECU View）和组件视图（Component View）三个部分。

图2.4.1：AUTOSAR方法学示意图，展示了系统视图、ECU视图与组件视图之间的关联关系

简单来说，系统视图包含软件组件的相关描述，同时会在此视图中完成配置，并将配置好的组件分配给特定的ECU。

在ECU视图中，通过对目标文件进行链接，生成可执行程序。本质上，ECU视图中的配置工作是指选择并配置基础软件（Basic Software）的模块，这些模块是实现任务调度器配置与功能所必需的。

组件视图为ECU视图提供目标文件（以二进制代码形式存在），并借助其组件相关模板，协助ECU视图生成可执行程序。

2.3 AUTOSAR背景

AUTOSAR旨在通过提高软件模块的可复用性和可交换性，优化复杂性管理，同时实现ECU软件架构的标准化。

如今的ECU承担着增强机电系统功能的作用。控制软件通常是针对目标车辆设计和开发的，在车辆的使用寿命内基本不会发生根本性变更。

在AUTOSAR标准出现之前，软件与硬件之间存在高度依赖关系，这种依赖关系可通过图2.5.1进行说明。

图2.5.1：在图（A）中，硬件和软件相互依赖，在图（B）中，AUTOSAR标准层不依赖于硬件

AUTOSAR架构为ECU软件设置了多个抽象层，即AUTOSAR分层软件架构，具体包括应用相关代码（应用层，Application Layer）、运行时环境（Run-Time Environment，RTE）、硬件相关代码（基础软件，Basic Software，BSW）以及 ECU 硬件（微控制器，Microcontroller）。

AUTOSAR的目的在于实现软硬件解耦，缩短开发时间并降低成本，同时通过软件复用提升质量与效率。

2.3.1 AUTOSAR标准

AUTOSAR包含两个标准化软件平台 —— 经典平台（Classic）和自适应平台（Adaptive），如图2.6.1所示。本项目将重点聚焦经典AUTOSAR。

图2.6.1:图（A）为经典 AUTOSAR（AUTOSAR Classic）及其分层结构；图（B）为自适应 AUTOSAR（AUTOSAR Adaptive）及其分层结构

2.3.1.1 经典平台

经典平台的技术特点如下：

·  基于OSEK标准（汽车电子开放式系统及其接口标准）。

·  代码直接从只读存储器（ROM）中执行。

·  所有应用程序共享同一地址空间（支持内存保护单元MPU，以保障安全性）。

·  针对基于信号的通信（如CAN、FlexRay）进行优化。

·  任务配置固定。

·  仅包含规范定义。

2.3.1.2 自适应平台

自适应平台的技术特点如下：

·  基于POSIX（可移植操作系统接口）标准。

·  应用程序从持久化内存加载到随机存取存储器（RAM）中运行。

·  每个应用程序拥有独立的（虚拟）地址空间（支持内存管理单元MMU）。

·  支持基于服务的通信。

·  支持多种（动态）调度策略。

·  同时包含规范定义与代码实现。

2.4 软件组件

软件组件（SWC）是模型中的最小组件单元，由端口（Ports）、内部行为（Internal Behavior）和功能实现（Functional Implementations）构成。这些组件可存在于应用层（Application Layer）、运行时环境层（RTE Layer）和基础软件层（BSW Layer）中。

端口用于实现一个软件组件与另一个软件组件的连接，同时也用于在不同软件组件之间或软件组件与RTE之间传输数据。软件组件上的基本端口类型包括提供者端口（PPort，Provider Port）、需求者端口（RPort，Require Port）以及提供者-需求者端口（PRPort，Provide Require Port）。

软件组件的功能实现被称为可运行实体（Runnable）。一个软件组件通常包含一个或多个可运行实体，每个可运行实体内部都包含一系列指令序列。可运行实体的形式与普通函数类似，其作用是描述软件组件的行为。软件组件代码可用于实现完整的应用程序，也可用于实现应用程序的一部分功能。

AUTOSAR包含多种类型的软件组件，本项目仅使用组合软件组件（Composition SWC）和软件组件连接器（SWC Connectors）。

组合软件组件（Composition）用于封装一个或多个软件组件（SWC）。与普通软件组件类似，组合软件组件也可拥有端口，用于接收和/或发送信息。外部连接通常通过组合软件组件的端口接入，再传递至组合内部的软件组件；连接器（Connectors）则用于表示两个软件组件的端口之间的连接关系。图 2.8.1 展示了组合软件组件与连接器的连接方式。

图2.8.1：组合对象与软件组件连接示意图。图中包含一个组合组件，内部有两个软件组件（SWC），通过端口（PPORT、RPORT）和连接器实现连接）

其他类型的软件组件还包括应用软件组件（Application SWC）、传感器/执行器软件组件（Sensor/Actuators SWC）、参数软件组件（Parameter SWC）、服务代理软件组件（Service Proxy SWC）等。

2.5 AUTOSAR基础架构

如前所述，AUTOSAR架构为ECU软件设置了多个抽象层。

基础软件（BSW）层进一步细分为四个子层，分别是服务层（Services Layer）、ECU抽象层（ECU Abstraction Layer）、微控制器抽象层（Microcontroller Abstraction Layer）和复杂驱动层（Complex Drivers），如图2.9.1所示。

图2.9.1：AUTOSAR模型及BSW分层示意图

AUTOSAR的目标是实现硬件组件的抽象化。各层向上层提供功能支持，即微控制器为BSW层提供功能，BSW层为RTE层提供功能，以此类推。分层架构具有诸多优势，例如当某一层出现错误时，仅需修复该层即可，无需对所有层进行调整。

2.5.1 应用层

应用层由相互连接的原子级应用软件单元（即软件组件）构成。该层中的每个软件组件都封装了ECU所需的全部或部分汽车功能及行为。

2.5.2 运行时环境

在AUTOSAR架构中，运行时环境（RTE）的任务是提供服务和资源，实现不同软件组件之间的通信。RTE支持两种通信类型：一种是ECU内通信（Intra-ECU Communication），即映射到同一ECU上的软件组件之间的通信；另一种是ECU间通信（Inter-ECU Communication），该通信需借助CAN、LIN、FlexRay等总线实现。

RTE的核心作用是使软件组件独立于其所在的ECU。软件组件的依赖性仅体现在其所依附的应用程序上，这意味着RTE必须针对特定ECU进行适配。这种适配通过ECU专属的生成与配置实现，因此，不同ECU上的RTE存在差异。

2.5.3 基础软件

如前所述，基础软件（BSW）层包含四个子层，如图2.9.1所示。

服务层（Services Layer）：

服务层为应用程序提供基础服务和基础软件模块，是BSW层的最上层。其提供的功能涵盖操作系统支持、车辆网络通信与管理、内存服务、诊断服务及ECU管理等。

ECU 抽象层（ECU Abstraction Layer）：

ECU抽象层使上层软件与ECU硬件布局解耦。它与微控制器抽象层对接，为上层提供外设和设备的访问接口，同时提供用于与微控制器交互的应用程序编程接口（API）。

微控制器抽象层（Microcontroller Abstraction Layer）：

微控制器抽象层可直接访问微控制器的片内外设模块和外部设备，同时使上层软件与微控制器硬件解耦。

复杂驱动层（Complex Drivers Layer）：

复杂驱动层用于操控复杂的传感器和执行器，实现其功能并满足时序要求。该层可直接访问微控制器，实现硬件与RTE之间的连接。

2.6 控制器局域网

控制器局域网（CAN）由博世（BOSCH）公司开发，是一种多主站、消息广播式网络。CAN最初专为汽车行业设计和应用，但目前也广泛应用于航空、机器人等领域。

与以太网（Ethernet）或通用串行总线（USB）等传统网络（采用点对点方式传输大量数据块）不同，CAN网络会向整个网络广播多个短消息。CAN的优势之一是能够确保系统中每个节点的数据一致性。在ISO 11898标准中，CAN帧分为两种类型：标准CAN帧（Standard CAN）和扩展CAN帧（Extended CAN）。

2.6.1 标准CAN帧

图2.10.1所示的标准CAN帧包含以下位域：

· SOF（Start of Frame，帧起始位）： 标记消息的开始，用于实现总线上各节点的同步。

· 11位标识符（11-bit Identifier）： 定义消息的优先级，二进制数值越小，优先级越高。

· RTR（Remote Transmission Request，远程传输请求位）： 当需要从其他节点获取信息时使用。

· IDE（Identifier Extension，标识符扩展位）： 表示当前传输的是标准CAN帧，无标识符扩展。

· r0（保留位）： 预留位，供未来可能的功能扩展使用。

· DLC（Data Length Code，数据长度码）： 指示通过CAN总线传输的数据字节数。

· 数据域（Data）： 最多可传输8字节的应用数据。

· CRC（Cyclic Redundancy Check，循环冗余校验位）： 包含前序应用数据的校验和，用于错误检测。

· ACK（Acknowledges，确认位）： 包含2位，其中显性位表示消息已无错误发送，另一位为界定符。

· EOF（End-of-Frame，帧结束位）： 标记CAN消息的结束。

· IFS（Interframe Space，帧间间隔）： 包含控制器将数据传输到目标缓冲区所需的时间。

图2.10.1.1：标准CAN帧结构示意图

2.6.2 扩展CAN帧

扩展CAN帧与标准CAN帧的结构基本一致，仅额外增加了三个位域，如图2.10.2.1所示。

图2.10.2.1：扩展CAN帧结构示意图

· SRR（Substitute Remote Request，替代远程请求位）： 在标准CAN帧中 RTR位的位置占位，替代其功能。

· IDE（标识符扩展位）： 该位为隐性位时，表示标识符位数扩展7位（即总标识符长度为29位）。

· r1（额外保留位）： 扩展CAN帧中额外增加的一个预留位。

03. 系统架构

本章将介绍系统所包含的组件、各组件的功能的以及组件之间的通信方式。

本项目使用的系统包含三个主要组件，如图3.1所示。第一个组件是输入数据源：本项目中的输入数据通过相应的API从互联网获取到个人计算机（PC）中；第二个组件是ECU：收集到的数据通过CAN总线传输至ECU，由ECU对输入数据进行处理后，将信息传递给第三个组件——LED；LED的任务是将接收到的信息以滚动字母和/或数字的形式显示出来。

图3.1：系统高层抽象示意图

04. 方法与工具

本章将介绍本项目/系统开发过程中所使用的方法、库、API、工具、硬件及软件。

4.1 方法

本项目主要采用极限编程（XP）方法，核心是两人一组协作开发，遵循40小时工作周、简化设计、测试驱动、重构优化、代码集体所有及编码标准统一等原则。办公室其他团队采用Scrum方法开展工作，本项目团队也参与了他们的每日站会。

选择极限编程方法的主要原因是：XP更侧重于实际编程实践，而Scrum更聚焦于项目管理与组织协调，二者针对不同领域，可形成互补。

4.2 编程语言与库

ECU编程采用C语言。为符合AUTOSAR标准，ECU被设计为一个软件组件（即“可运行实体”），其唯一功能是控制LED如何输出输入数据。ECU通过SPI总线向LED传输数据，这需要使用符合AUTOSAR标准的SPI库。同时，项目还使用了C语言的标准库，如string.h（字符串处理库）和stdlib.h（标准通用库）。

项目使用Python新版本（3.7.3）编写脚本，通过CAN通信将数据传输至ECU。其中，Kvaser Leaf Light v2作为连接器，实现PC与CAN总线的连接。该Kvaser连接器提供了一个Python CAN库接口（CANlib），支持数据的发送与接收。

4.3 工具

ARCCORE公司为项目提供了两台计算机，并预装了所有必需的软件。其中，Arctic Studio作为集成开发环境，用于开发和编译APA102型LED的控制程序；WinIDEA 软件用于将编译后的程序下载到 MPC5748G（ECU）中，并实现调试功能。

项目采用Git进行版本控制，所有源代码均存储在ARCCORE公司的Bitbucket 代码仓库中。

数据源与ECU之间的通信通过Kvaser Leaf Light v2实现，该设备是一种用于连接计算机与CAN总线的线缆。APA102型LED仅支持二线制SPI通信，项目中使用的SPI通信库由Arctic Core提供。

为将270个LED组成30×9的矩阵，项目使用Weller WHS 40焊接台完成LED的焊接（按设计阵型拼接），并焊接与ECU进行SPI通信所需的导线。

4.3.1 软件

4.3.1.1 Arctic Studio

Arctic Studio是由ARCCORE公司开发并维护的开源集成开发环境（IDE），符合AUTOSAR标准，基于Eclipse平台构建。借助Arctic Studio，客户可采用组件化开发方式，为汽车行业开发应用程序。

4.3.1.2 Arctic Core

Arctic Core是ARCCORE公司开发并维护的软件包，为汽车ECU提供通信服务、诊断服务和安全服务。该软件包基于AUTOSAR标准开发，支持软件复用。

4.3.1.3 WinIDEA

WinIDEA是一款用于将编译后的程序下载到微控制器中的软件工具，同时也可用于调试。

4.3.1.4 Git

Git是一款免费开源的版本控制系统，可用于管理从小型到大型的各类项目。

4.3.1.5 Jenkins

Jenkins是一款开源自动化服务器软件，支持包括Git在内的多种版本控制工具。

4.3.1.6 SPI

SPI（Serial Peripheral Interface，串行外设接口）主要用于嵌入式系统中的短距离通信。

4.3.2 硬件

4.3.2.1 MPC5748G

MPC5748G是恩智浦（NXP）公司生产的一款用于开发的微控制器，兼容以太网、USB、CAN和LIN等多种通信方式。

4.3.2.2 Kvaser Leaf Light v2

Kvaser Leaf Light HS v2是实现计算机与CAN总线网络连接的简便且低成本的设备之一。

4.3.2.3 APA102

APA102是DotStar公司生产的一款集成微控制器的RGB（红绿蓝）LED，采用通用二线制SPI协议进行通信。

4.3.2.4 Weller WHS 40

Weller WHS 40是一款主要用于爱好者焊接工作的焊接台。

05. 实施过程

本章将从技术层面阐述整个系统的实现方式，同时说明系统各部分的测试过程。

5.1 电子控制单元（ECU）

ECU的实现符合AUTOSAR标准，这意味着它被设计为一个软件组件，即“可运行实体”（Runnable）。本项目中使用的ECU仅承担一项任务——控制LED，因此该ECU仅包含一个可运行实体。

5.2 ECU与LED通过SPI通信

ECU的任务是处理输入数据，并对数据进行转换，使APA102型LED能够理解接收到的数据。APA102型LED支持二线制串行外设接口（SPI）通信，这两条总线可分别传输数据信号和时钟信号，时钟信号会定期读取数据信号。数据总线由多个帧组成，这些帧定义了单个LED的亮度和显示颜色。如图5.2.1所示，每个帧以32位为一个数据块。

图5.2.1：APA102型LED帧数据手册示意图

要向APA102型LED发送指令，需依次发送起始帧（Start Frame）、LED帧（LED Frame）和结束帧（End Frame），以下将对这三种帧进行详细说明。

5.2.1 起始帧

起始帧由32个二进制“0”组成，长度为32位，如其名称所示，用于标记一个数据帧的开始。

5.2.2 LED帧

LED帧用于指定LED的亮度和显示颜色。该帧的前3位必须始终为“1”；接下来的5位称为“全局位”（Global Bit），用于设置LED的亮度，取值范围为00000（最低亮度）至11111（最高亮度）；最后24位用于定义颜色，采用BGR（蓝-绿-红）格式。

5.2.3 结束帧

结束帧由32个二进制“1”组成，用于标记一个数据帧的结束。

ECU会定期、持续地向LED传输数据帧，告知LED如何显示数据，这一过程借助AUTOSAR SPI库接口实现。

项目中使用两个函数来设置通信通道和传输数据，分别是SetupEB()函数和Spi_SyncTransmit()函数。

图5.2.2中的代码用于为SPI总线设置一个通道。其中，第一个参数为通道ID；第二个参数为数据缓冲区，是一个存储待传输数据的数组，该数据需按照上述APA102型LED帧的数据手册格式进行格式化；第三个参数为从APA102型LED读取数据的缓冲区，由于ECU仅向LED发送数据而不读取数据，因此该参数设为NULL；最后一个参数为待发送和/或接收数据的长度。

图5.2.2：为SPI总线设置通道的函数代码

图5.2.3中的函数用于通过SPI总线同步传输数据，传输的数据即为前一个函数中指定的SrcDataBufferPtr（源数据缓冲区指针）所指向的数据。

图5.2.3：向SPI总线同步传输数据的函数代码

5.3 ECU与LED通信测试

为验证硬件是否正常工作，项目使用PicoScope示波器（配合PicoScope 6软件）进行测量，如图5.2.4所示。测试过程中，向两个LED发送红色显示指令，同时测量时钟信号和数据信号。测量完成后，将PicoScope 6软件显示的可视化结果与APA102型LED帧数据手册进行对比，验证数值是否匹配。

图5.2.4：测量数据图表。红色信号为数据信号，蓝色信号为时钟信号，展示了向两个LED发送最低亮度红色显示指令时的信号情况，包含起始帧（32位）、两个LED帧（各32位）

5.4 在LED上实现数据可视化

ECU以字母和/或数字的形式实现数据可视化。具体而言，项目将字母表中的所有字母和数字按照30×9的坐标系，逐LED进行硬编码，并存储在一个数组中。这种设计便于对输入字符串进行解码，并在LED上实现可视化显示。

图5.4.1：在LED上显示文本的函数代码

图5.4.2：在LED上显示单个字符的函数代码

图5.4.3：LED面板数据可视化示意图。该图展示了文本滚动效果：从状态1开始，到状态9结束后，可视化数据会循环回到状态1，这意味着固定字符的偏移量会持续变化）

5.5 ECU与数据源/输入数据通过CAN通信

ECU通过CAN通信从输入数据源接收数据。为向ECU发送数据，项目借助CANlib库中的函数执行Python脚本：脚本首先从API获取待可视化的数据（具体数据类型可自定义），将其转换为ASCII码后发送至ECU。

项目中实现的一种输入数据源是从Jenkins（自动化服务器）获取构建和测试数据。这些数据来自ARCCORE公司自用的Jenkins服务器，员工的软件构建和测试记录均存储于此。项目通过Jenkins Python API获取特定时间段内成功的构建和测试次数。若要显示其他类型的数据，可采用类似流程，只需获取相应 API 的访问权限即可。例如，若需可视化某一地区的实时天气数据，可从互联网上获取各类天气API。

图5.5.1展示了将字符串“Hello World”通过CAN总线传输至ECU的部分代码。该字符串被拆分为单个字符，每个字符存储在一个8位的帧中（如createAndSendFrame()函数所示）。由于ECU会几乎同时接收到所有帧，可能导致无法区分各个ASCII码，因此在每个字符后会发送一个唯一字符，用于标记下一个字符即将传输。

图5.5.1：向ECU发送“Hello World”的脚本代码

5.6 CAN总线测试

为验证CAN通信是否正常，项目使用PicoScope示波器进行测量。将所有硬件连接完成后，通过CAN总线发送300帧数据：CAN_H（CAN高电平线）的电压约为3.75V，CAN_L（CAN低电平线）的电压降至约1.2V；当两条线路的电压均达到约2.5V时，CAN总线处于空闲模式，表明此时无数据在总线上传输。

图5.6.1：使用PicoScope 6软件向ECU发送300帧数据时的测量结果图表，电压范围为1.033V-4.008V，包含CAN_H和CAN_L的电压变化曲线）

5.7 ECU程序测试

项目采用单元测试的方式对代码进行测试，即对独立的函数（作为短代码片段）进行测试。单元测试通常要求测试用例相互独立，选择对部分函数进行单元测试，是为了验证这些独立模块的正确性。

为实现测试用例，项目创建了“mock.h”文件。模拟对象（Mock Object）与复杂对象具有相同的接口，例如AUTOSAR中的SPI函数Spi_SyncTransmit(Spi_SequenceType Sequence)。

复杂对象在测试中往往难以使用，而模拟对象可通过自定义实现来满足测试中的控制需求。

项目还创建了“test.h”文件，用于运行测试并打印函数运行结果（如图5.7.1所示）；“mock.h” 文件则用于存储上述 “复杂” 函数（如图 5.7.2 所示）。测试在命令行（cmd）中执行，所有打印信息均在命令行中显示（如图 5.7.3 所示）。

图5.7.1：“test.h”文件代码示例，包含testTextStringOnMessage()、testWriteCharForWJ()、testSyncTransmit()、checkErrorCodeIncrementErrors()等函数。其中，testWriteCharForWJ()函数通过调用程序代码中的writeChar()函数，打印出LED面板显示字符“W”和“J”的宽度（分别为10和5）；testSyncTransmit()函数用于测试数据传输功能是否符合预期）

图5.7.2：“mock.h”文件中的Spi_SyncTransmit()函数代码，该函数在“test.h”文件中调用，返回类型为uint8

图5.7.3：命令行打印结果示例，显示testWriteCharForWJ()和testSyncTransmit()函数的运行输出

06. 结果

6.1 技术成果

本项目构建的系统用于传输来自Jenkins（一款采用Java编写的开源自动化服务器）的数据。Jenkins作为基于服务器的系统，会发送各类通知信息，如“失败（False）”“成功（Success）”、用户名（username）、消息（msg）、编号（number）等。

该自动化服务器在ARCCORE公司办公室中配合Git插件使用。本项目开发的系统作为客户端，会从Jenkins服务器获取这些通知信息并传入Python程序，客户端每60秒监听一次服务器的新通知。

为确保程序正常运行，Python脚本需持续运行，通知信息会进一步发送至ECU，最终在LED面板上显示。

Python脚本可视为服务器与ECU之间的“桥梁”，起到网关作用：从Jenkins服务器获取的消息通过CAN总线转发至ECU，结果最终显示在LED面板上，具体系统架构可参考第3节“系统架构”中的图3.1。

借助Arctic Studio软件，项目团队得以使用AUTOSAR的相关函数；通过C语言编程，搭建了CAN、SPI及其他必要工具的数据采集与传输通信链路；在Arctic Studio中，还搭建了字母和数字的显示系统，确保这些字符能在LED面板的对应灯珠上点亮显示。

LED面板上显示的字母和数字会沿X轴（向左）移动，移动的文本长度根据输入内容计算；当滚动文本完全移出视野后，会从右侧重新开始向左滚动，具体效果可参考前一节（第5节）中的图5.4.3。此外，LED预先编程为以2毫秒（ms）的速度点亮，这是项目能实现的最快速度；若在程序执行过程中中途停止，可能会出现数字显示错误，如图6.1.1所示。

图6.1.1：LED显示效果对比图。图（A）显示正常滚动时的文本“SU00E551556E55”；图（B）中箭头标注了LED面板的焊接连接方式，状态1直接与ECU连接。程序正常运行时，字母/数字以2毫秒的速度移动，从人眼视角看字符是完整的；而在图（B）中，程序执行中途停止，可见状态1、2、3、4的偏移量比其他状态多移动了一步，导致显示异常）

6.2 LED显示屏的使用与调整

LED面板将安装在ARCCORE公司工具团队办公室的墙上，向办公室所有员工展示最新的提交构建记录以及成功构建的次数，具体安装布局如图6.2.1所示。目前，程序运行在一台PC上；未来ARCCORE员工可能会对硬件进行调整，将PC替换为更合适的设备（如树莓派（Raspberry Pi））。

图6.2.1：ARCCORE工具团队办公室布局示意图。墙上的LED面板显示“SUCCESS 1”（成功构建1次），系统包含员工电脑（Employees PCs）、Jenkins服务器（Jenkins）、运行中的Python网关（Running Python Gateway）、互联网（Internet）、CAN总线（CAN）、ECU、SPI总线（SPI）等组件及连接关系，其中Jenkins服务器位于ARCCORE办公室外部）

Python程序的功能是从Jenkins服务器获取通知信息。本项目中，系统主要监听三种通知类型：“成功（SUCCESS）”、“通过次数（passCount）”和“失败次数（failCount）”。

其中，“SUCCESS”用于条件判断（if-else语句）：若在最新提交的构建记录中检测到“SUCCESS”，LED面板将显示类似“SUCCESSFUL BUILDS 1234”的内容（例如“1234”为Jenkins发送的“passCount”，即成功构建次数）；若未检测到“SUCCESS”，则显示类似“FAILED BUILDS 1234”的内容（其中“1234”为Jenkins发送的“failCount”，即失败构建次数）。图6.2.2展示了LED面板可能的输出效果及对应显示颜色。

图6.2.2：LED面板输出效果示意图，示例显示文本“SESEPP”）

若需新增其他通知类型，需在Python文件中编写相应代码；文本颜色的设置则通过C程序实现，即需为不同消息类型指定对应颜色——文本和数字的默认颜色为红色，背景色始终为白色。

6.3 结果讨论

本系统仅支持显示大写字母，这一设计主要是因为在30×9的LED面板上，小写字母的显示效果不佳，难以清晰识别。若同时显示大小写字母和数字，还可能造成视觉混淆；若要解决这一问题，可采用更大尺寸的LED面板，但本项目无需额外扩展该功能。

项目团队曾在LED面板上进行过多种测试，包括显示不同颜色、闪烁效果等，但这些功能与本项目的核心实现目标无关，因此未纳入最终方案。仅硬编码所有字母和数字就已耗费大量时间，若有更多时间，可进一步实现更丰富的彩色消息显示功能。

07. 讨论

7.1 项目需求的完成情况

项目完成后，团队发现并非所有需求都已实现。在实施过程中，团队意识到部分功能的实现难度超出预期，尤其是在Arctic Studio中需要进行大量配置工作，才能确保硬件正常运行。

本项目基于一个名为“HelloWorld”的AUTOSAR项目搭建基础框架，该项目中已预先定义了SPI、CAN、端口（Ports）及波特率、通道、数据宽度、软件组件（SWCs）等属性，但团队仍需对这些预设属性进行调整，以适配本项目的需求。图7.1.1展示了Arctic Studio中的基础软件（BSW）编辑器界面。

图7.1.1：“HelloWorld8”项目的BSW编辑器界面

配置工作所耗费的时间超出预期，尤其是在实现ECU向LED发送数据的功能时，频繁出现硬件问题。团队需要仔细检查焊接情况，并使用万用表和PicoScope示波器进行测量，以确认数据是否按预期传输。

在选择CAN连接或以太网连接时，团队进行了对比分析：由于所使用的ECU同时支持CAN和以太网，最终决定通过CAN传输数据。原因在于，1Mbps速率的CAN总线比10Mbps速率的标准以太网/TCP/IP具有更高的帧率，且CAN通信安全性更高；若采用以太网连接，需额外使用TCP/IP等更高层级的协议，以确认发送的帧是否被丢弃，而CAN协议本身具备无冲突总线仲裁、多主站与广播通信、响应时间受协议软件处理时间限制、数据完整性保障等特性，可直接实现安全传输。

7.2 预期结果

项目总体达到了预期目标。团队起初并未期望完成所有需求，因为此前对AUTOSAR的了解有限，也不确定该平台能否适配项目构想。团队与ARCCORE在项目准备阶段的工作较为充分，但在硬件调试过程中仍遇到较多问题，需要大量排查工作。

最终成果与项目启动前团队和ARCCORE在会议中讨论的方向一致。原本计划的下一步是集成传感器，但传感器采集的信息并非办公室“必需”的展示内容；相比之下，将Jenkins服务器的实时数据发送至办公室LED面板，对员工而言更具实际价值。

7.3 从结果中得出的结论

本项目在AUTOSAR平台上实现了预期功能且无故障运行，这一成果具有重要意义，因为它为两个研究问题提供了实践依据。

对于第一个研究问题 ——“在与汽车行业无直接关联的设备上，是否能够实施AUTOSAR标准？”，无法简单给出“是”或“否”的答案。原因在于本项目系统较为简单，仅使用了一个“可运行实体”（Runnable），虽能无故障运行，但若增加更多软件组件，程序可能会变得混乱，且需要大量额外配置才能正常工作。若要将AUTOSAR应用于更复杂、与汽车无直接关联的系统，或许能得出更具说服力的结论——复杂系统的应用场景能更充分地利用AUTOSAR的特性，并测试其应用边界。

对于第二个研究问题——“在与汽车行业无直接关联的系统中，AUTOSAR的运行表现如何？”，本项目系统的运行表现良好。但如前所述，团队需对各类模块进行大量调整；且由于AUTOSAR平台上运行的程序比Python程序稍慢，需通过睡眠函数（sleep functions）来协调CAN总线的数据传输时序。

若本项目不使用AUTOSAR，系统性能可能会更优——移除AUTOSAR的抽象层后，代码可更精简，且能对系统各环节实现更直接的控制。

综上可得出结论：AUTOSAR适用于本项目规模的任务。AUTOSAR内置的函数简化了许多开发工作，其分层架构使团队能通过调整ECU，实现对所开发系统的全面控制。从图6.1.1也可看出，所使用的软件能清晰地展示待配置的组件，操作便捷性较高。

7.4 社会与环境影响

本项目开发的LED可视化面板在市场上并非创新产品——类似的显示设备广泛应用于超市（如显示“欢迎光临”）、火车站（如显示到站与发车信息）等场景。本项目产品与其他同类产品的核心区别在于，它基于AUTOSAR平台构建。若未来能将本项目进一步开发为信息娱乐系统（这也是项目的潜在最终目标），其对社会、环境及实际生活的影响将显著提升。

十年前，汽车中尚未普及信息娱乐系统；如今，随着智能手机的普及，汽车信息娱乐系统也日益大众化。随着汽车的控制方式从机械控制向自动控制转变，信息娱乐系统极大地提升了驾驶的便利性——例如，倒车影像功能大幅降低了停车难度，这是信息娱乐系统的积极应用案例。

但信息娱乐系统也存在负面影响：这类系统通常能通过CAN总线访问汽车的各类功能，这意味着车辆存在被第三方设备通过黑客技术远程控制的风险（如“线控驾驶”劫持）。

此外，随着汽车数字化程度不断提高，环境负担也随之加重。电子设备的废弃量已十分庞大，而信息娱乐系统的普及将进一步增加电子废弃物的产生。电子废弃物中含有大量有害物质和化学物质，这些物质在废弃处理过程中会释放到环境中，对全球环境及人类健康造成负面影响。

7.5 项目发展潜力

若有更多时间，团队可实现此前规划的低优先级需求——集成传感器（如采集办公室温度数据，并在LED面板上显示）。此外，还可添加物理按键实现更多功能：若系统需从多个数据源采集数据，可通过物理按键切换LED面板显示的数据类型，这需要在代码中新增相应的控制函数。

未来，本项目可进一步开发为采用自适应AUTOSAR（Adaptive AUTOSAR）的信息娱乐显示屏——这类显示屏目前已广泛应用于汽车领域。如今，许多现代汽车都配备了信息娱乐系统，但普遍存在一个问题：驾驶过程中难以安全使用。解决该问题的一个方案是在系统中集成语音指令功能——用户可通过语音获取所需信息，从而将注意力集中在驾驶上。希望未来本项目的开发能朝着这一方向推进，以解决当前信息娱乐系统存在的核心痛点。

就目前而言，本项目已具备坚实的基础，ARCCORE可根据办公室的实际需求，进一步调整其功能，使其更贴合使用场景。