摘要
本文探讨了通过采用面向服务的架构（SOA）实现车辆照明系统的转型。传统的单体软件设计与分布式电子电气（E/E）架构紧密绑定，限制了系统的可扩展性并增加了开发复杂性。通过将照明功能模块化设计为微服务并部署在集中式计算平台上，能够在灵活性、可复用性和可维护性方面获得显著优势。文中提出了一种照明服务的功能分类方法，涵盖美学类、信息类、强制类和娱乐类四大类别。关键应用场景包括车与万物互联（V2X）自适应近光控制和拓扑依赖式调平功能。这些示例展示了如何利用标准化接口（API）和持续集成 / 持续部署（CI/CD）流水线，实现照明功能的独立开发、更新，并跨车辆平台部署。所提出的方法能够加快创新周期，支持量产（SOP）后的功能升级，并减少系统级集成工作量。最终，该方法将外部照明定位为软件定义汽车（SDV）生态系统中一个完全集成的组件。
1. 引言
当今的汽车外部照明系统基于分布式电子电气（E/E）架构构建，照明功能通过多个电子控制单元（ECU）执行，这些 ECU 通常集成在灯壳内部。这导致系统复杂性高、材料成本增加，并且在软件集成和维护方面面临越来越多的挑战。电子控制单元（ECU）变体的激增进一步凸显了对稳健更新架构的需求，推动了架构变革。对于管理传统平台的原始设备制造商（OEM）而言，向域导向型架构转型提供了一条过渡路径。核心照明功能（如自适应远光（ADB））与硬件解耦并集中在域控制器（ECU）中，实现了硬件无关的软件架构。下一步演进是在区域电子电气（E/E）架构中采用集中式高性能计算机（HPC），其中区域控制器（ECU）负责管理外围设备的电源供应和通信。
与此同时，即使对于高清投影等复杂功能，照明系统也正朝着无软件设计的方向发展，从而降低硬件成本和复杂性。这些架构变革直接影响软件设计：单体式照明应用必须演进为模块化、面向服务的架构。我们的方法并非将所有功能整合到单个电子控制单元（ECU）中，而是主张将照明功能分解为微服务。图 1 左侧展示了当前的技术现状，右侧则呈现了未来的理想架构。这种方法支持灵活部署、提高可维护性，并更好地与未来软件定义汽车（SDV）生态系统保持一致。面向服务的架构（SOA）原则可以逐步应用 —— 从基于域的系统到完全集中式架构 —— 提供可扩展性和长期适应性。
图1、从单片设计（左）到微服务（右）
2. 行业挑战
2.1 传统电子电气（E/E）架构中的模块化问题
分布式电子电气（E/E）架构依赖高度优化的嵌入式软件，这些软件针对特定的硬件约束进行定制，尤其是在边缘设备中。在汽车照明领域，这导致单个电子控制单元（ECU）内的软件紧密耦合，每个电子控制单元（ECU）专门负责控制特定的照明模块，从而限制了灵活性和可复用性。为克服这些限制，本文提出了一种模块化架构。照明功能被划分为通用服务（例如基于车辆或环境状态的驾驶模式）和设备特定驱动程序。这种解耦允许平台无关的服务通过即插即用的方式在不同车型系列中复用，而硬件特定驱动程序则通过标准化抽象与系统交互。这种基于微服务的设计减少了对特定电子电气（E/E）配置的依赖，并支持可扩展部署。然而，为满足实时性能要求 —— 尤其是对于自适应照明或投影等高级功能 —— 带有硬件加速器（如图形处理器（GPU））的片上系统（SoC）仍然至关重要。
2.2 通过集中化、标准化和持续集成 / 持续部署（CI/CD）实现可扩展照明
随着照明功能计算强度的增加以及在边缘设备上的分布式部署，系统复杂性和开发成本急剧上升 —— 尤其是当多个供应商使用不兼容的工具链和持续集成 / 持续部署（CI/CD）流水线时。这种碎片化环境导致软件栈不一致、授权工作重复以及集成延迟。
通过域控制器（ECU）或高性能计算机（HPC）集中计算资源，为简化开发提供了机会。架构、接口和交付格式（如容器）的标准化是关键。容器化技术支持照明微服务的可重现、平台无关部署，并由现代持续集成 / 持续部署（CI/CD）流水线提供支持。这种方法支持一致且自动化的构建和测试流程，确保软件发布的可靠性和可重复性。版本控制环境增强了可追溯性，并支持长期可维护性。通过签名和验证的服务包增强了安全性，同时简化的空中下载（OTA）更新和回滚机制使部署更加灵活。
总之，这种统一的工具链策略加快了开发速度，促进了软件复用，并确保在量产（SOP）时交付经过认证的基准版本。量产（SOP）后，它支持动态功能配置 —— 例如个性化照明动画或特定区域的灯光特征 —— 支持持续创新，并将外部照明定位为软件定义的体验平台。
2.3 照明系统中僵化的软件结构对灵活性的阻碍
传统上，即使内部设计是模块化的，照明软件也会被编译成一个单一的大型二进制文件。因此，任何更改 —— 无论是错误修复、功能更新还是扩展 —— 都需要重新构建整个程序。这种紧密耦合的方法使开发变得复杂，尤其是在照明与其他应用程序共存的集中式系统中。照明系统还依赖大量校准参数来微调性能，而无需修改代码。随着时间的推移，这些参数的数量不断增加，导致内存使用率上升，并使配置管理更加复杂。针对不同市场或变体的校准集，在制造过程中和现场更新时都需要复杂的架构支持。这种结构难以管理个性化功能的持续开发和部署，即使是简单的灯光动画也是如此。核心问题在于软件逻辑与固定系统资源的僵化耦合。
2.4 照明功能在高级驾驶辅助系统（ADAS）中的应用
高级驾驶辅助系统（ADAS）在提升安全性和舒适性方面发挥着关键作用，外部照明通过近光调平、无眩光远光和符号投影等功能做出贡献。其中许多功能依赖于非照明系统的输入，例如前视摄像头的目标检测数据。然而，照明和高级驾驶辅助系统（ADAS）功能通常是独立开发的，导致时间线不一致和互操作性有限。无眩光远光很好地说明了这一挑战，它需要与目标检测更新进行持续协调。如果在功能需求上没有早期对齐，集成将变得复杂，降低系统效率并导致基于权宜之计的解决方案。当照明被用于积极支持高级驾驶辅助系统（ADAS）时 —— 例如通过调整光束模式以增强目标可见性或投影导航引导提示 —— 这一问题会更加突出。虽然潜力巨大，但成功实施需要更紧密的跨域协调和持续、对齐的开发工作。
2.5 面向服务的架构（SOA）照明系统的安全考量
设计车辆照明服务需要遵守既定的安全和安保原则，尤其是在从单体架构向面向服务的架构（SOA）转型时。这些原则 —— 如简洁性、明确的职责分离和可追溯的数据流 —— 必须尽早整合，以避免后期进行昂贵的重新设计。无论采用何种架构，ISO 26262 和 ISO/SAE 21434 等标准仍然适用。虽然面向服务的架构（SOA）不会降低安全和安保要求，但它提高了模块化和透明度，使验证和认证更加易于管理。这种结构化方法支持更快的评估，并增强了对系统完整性的信心 —— 随着车辆系统变得越来越复杂，这是一个重要优势。
3. 提出的方法和应用场景
为评估基于微服务的架构在车辆照明中的优势、劣势和特点，我们提出了四类分类方法，根据服务功能的目的和价值贡献进行分类：
1. 美学类 —— 塑造环境体验的服务，通过照明影响情绪或感知质量（例如心理测量效果）。
2. 信息类 —— 向车辆周围环境传达信息的服务，例如状态指示器或上下文驱动的消息（例如广告）。
3. 强制类 —— 为满足法律和安全法规而必需的服务，确保符合道路使用标准。
4. 娱乐类 —— 通过个性化或游戏化增强用户体验的服务。
根据这一分类，可以确定照明微服务的不同应用场景。
应用场景 1：基于车与万物互联（V2X）的自适应近光 ——“强制类与信息类” 集成
作为说明性示例，考虑一个与车与万物互联（V2X）基础设施集成的自适应近光应用场景。在这种情况下，车与万物互联（V2X）输入提供近光的动态调光值，使道路照明与当地街灯亮度保持一致。这种自适应调整有助于在外部照明已经充足时降低功耗和减少不必要的光线排放。
从面向服务的架构（SOA）角度，我们定义了两个不同的微服务（见图 2）：
· 强制类近光服务：处理物理灯光开关输入，并提供安全关键的调光目标值。
车与万物互联（V2X）近光服务：处理外部输入（例如车与万物互联（V2X）消息），以提供可选的调光目标值。
图2、控制近光灯的两种不同服务（用例1）
这两个服务由一个监控安全机制（例如通过虚拟机监控程序或专用安全控制器）进行监控和管理。关键的是，车与万物互联（V2X）服务在非安全关键路径中运行，以确保它不会影响必须始终满足 ASIL-B（或更高）安全标准的强制类近光服务。输出仲裁逻辑（即输出开关或多路复用器）也必须包含在安全路径中，以保证在所有条件下的一致和可观察行为。这种架构分离具有以下关键优势：
· 符合法规要求的照明功能安全完整性。
· 非关键服务（如车与万物互联（V2X））的模块化可扩展性。
· 独立的生命周期管理，允许车与万物互联（V2X）服务独立演进或故障，而不影响核心功能。
应用场景 2：作为娱乐服务的拓扑依赖式调平功能
作为娱乐类别的代表性应用场景，我们研究了一种旨在增强个性化和用户体验的拓扑依赖式调平功能。传统上，前照灯调平功能作为固定逻辑服务实现，基于预定义的车辆参数计算步进电机驱动程序的目标角度。这一核心功能通常是静态的且经过安全验证，几乎没有个性化或动态自适应的空间。相比之下，拓扑依赖式调平服务引入了新的以用户为中心的定制层。例如，系统可以根据车辆当前位置（如城市道路与乡村道路）、驾驶模式甚至驾驶员偏好来调整光束角度。为了在保留现有调平逻辑完整性的同时集成此功能，提出了以下基于面向服务的架构（SOA）的两步法：
架构准备 —— 服务层解耦
将标准调平逻辑与执行器（步进电机驱动程序）之间的直接链接解耦（见图 3 步骤 1）。引入一个中间切换服务，能够将多个调平输入路由到执行器。这允许在标准和个性化调平输出之间灵活选择。
图3、左：原始水平；右：两步扩展（用例2）
功能集成——拓扑基服务的部署
然后部署新的拓扑依赖式调平服务，并将其作为替代输入连接到切换逻辑（见图 3 步骤 2）。该服务在安全关键路径之外运行，可以独立更新、扩展或替换。它利用实时地图数据或地理位置输入，根据道路类型或环境动态调整前照灯位置。
这种方法具有以下几个关键优势：
· 个性化和舒适性：支持基于实际驾驶条件或用户偏好的动态灯光自适应。
· 模块化部署：允许分阶段推出，无需修改经过认证的基础功能。
· 隔离性和安全性：将标准调平服务保持在安全关键执行路径中，确保符合法规要求。
通过利用面向服务的架构（SOA），拓扑依赖式调平功能等特性成为灵活、模块化的附加组件，而不是紧密集成的单体。这支持了一个可扩展的生态系统，其中以娱乐为重点的服务可以随着用户需求的变化而演进，同时不影响基础安全功能。
这两个应用场景都展示了面向服务的架构（SOA）如何为车辆照明带来灵活和可扩展的开发。强制类安全关键功能被封装和保护，而扩展或个性化功能则独立引入。这种模块化降低了开发风险，支持灵活的功能交付，并与软件定义汽车（SDV）不断发展的需求保持一致。在未来的软件定义汽车（SDV）框架中，标准化的车辆照明接口（API）将发挥核心作用。该接口（API）将主要用于两个目的：
1. 控制各个照明功能；
2. 与其他车辆域（如高级驾驶辅助系统（ADAS））接口，以支持跨功能特性。
汽车照明供应商面临的关键挑战之一是将现有的单体照明算法转换为模块化、封装的微服务 —— 每个微服务都与特定的照明功能对齐。这些微服务需要能够独立运行，支持模块化更新和跨车辆平台复用。对于具有分布式传统电子电气（E/E）架构的原始设备制造商（OEM）而言，转型初期可能需要涉及混合架构。这些架构将弥合传统组件与新兴区域或集中式软件定义汽车（SDV）平台之间的差距。每个照明微服务都将有自己的开发和生命周期管理，并由标准化的持续集成 / 持续部署（CI/CD）流水线提供支持。这些流水线将包括：
· 自动化测试和验证；
· 安全部署机制；
· 数字签名或证书，以确保服务完整性和网络安全合规性。
这种方法不仅支持更快的创新周期，还确保了在多供应商软件定义汽车（SDV）生态系统中的法规一致性和长期可维护性。
4. 结论与展望
面向服务的架构（SOA）极大地改进了软件组件集成到车辆中的方式。关键是引入一个从底层到应用层的分层模型作为理想架构，包括层间的接口和协议。更高的目标是在操作系统之上实现稳健的中间件，因为它承载着以客户为中心的功能，但首先，当从传统架构过渡时，必须集成或迁移底层功能。一旦包括中间件在内的较低层成熟且稳健，上层服务和应用程序的开发速度就可以大大加快。通过灵活的设计，可以通过不同层虚拟建立垂直连接，实现从顶层到底层的直接信号流，适用于各个应用场景或应用程序。这种所谓的 “虚拟服务垂直层” 代表了传统的物理垂直集成，不同之处在于物理边界被打破，一层的变化不会影响更高层（见图 4）。这种理念适用于照明系统，特别是对于传统功能的转型和新可能性的实现。它是实现所讨论的应用场景的基础，并允许照明系统通过其自身的虚拟服务垂直层与不同域集成。
图4、SDV层模型
高级驾驶辅助系统（ADAS）越来越依赖外部照明服务 —— 例如，通过突出车辆周围的目标，提高摄像头传感器的可见性。在这种跨域应用中，传统的单体照明算法被证明效率低下，并且缺乏跨域实时处理所需的灵活性。
相比之下，将照明功能封装为各自具有特定功能生命周期的微服务，支持资源高效处理、更轻松的集成和有针对性的更新。这种模块化方法不仅提高了性能，还与可扩展软件定义汽车（SDV）平台的架构原则保持一致。此外，这种基于微服务的架构支持对用户特定和个性化照明功能日益增长的需求，特别是在信息娱乐、环境照明和交互式车辆通信等领域。服务可以独立开发、部署或升级，而不影响核心安全关键照明功能。
为实现并加速这一转型，标准化的车辆照明接口（API）至关重要。这些接口（API）充当核心照明功能和更高层域服务的通用接口。通过开源软件定义汽车（SDV）计划定义和发布这些接口（API）以及相应的服务设计，行业可以：
· 促进原始设备制造商（OEM）和一级供应商之间的互操作性；
· 鼓励在概念验证（PoC）项目上的合作；
· 验证与高级驾驶辅助系统（ADAS）、信息娱乐和环境传感系统的跨域集成。
这种开放和模块化的设计范式为面向未来、面向服务的照明架构奠定了基础，该架构具有适应性、安全性和可扩展性。
