网络通讯子系统

1. Document Information 文档信息

1.1 Purpose of the document 文档目的

本文档定义了智能座舱域控制器（IDC）网络通讯子系统的完整需求。其目的是为车辆提供稳定、高效、安全的全栈网络通信能力，支持车内外各种设备和服务的连接与数据交换，包括车内以太网通信、无线网络连接、远程通信、网络管理和网络安全，是车辆实现网联化、智能化、服务化的核心基础设施。

1.2 Scope of the document 文档范围

本文档适用于【公司或平台】的【具体项目或平台】的座舱域控制器。范围涵盖车载以太网协议栈、无线通信模块（Wi-Fi/蓝牙）、蜂窝网络（4G/5G）、网络管理、网络安全以及相关的诊断与配置需求。

1.3 Abbreviations, Terminology 缩略词术语

1.3.1 Abbreviation 缩略语

NO.	Abbreviation	Definition (local)
1	SOME/IP	Scalable service-Oriented MiddlewarE over IP，基于IP的可扩展面向服务中间件
2	DoIP	Diagnostic over IP，基于IP的诊断协议
3	TSN	Time-Sensitive Networking，时间敏感网络
4	VLAN	Virtual Local Area Network，虚拟局域网
5	TCP/IP	Transmission Control Protocol/Internet Protocol，传输控制协议/网际协议
6	APN	Access Point Name，接入点名称
7	SIM	Subscriber Identity Module，用户身份识别卡
8	QoS	Quality of Service，服务质量
9	VPN	Virtual Private Network，虚拟专用网络
10	NAT	Network Address Translation，网络地址转换

1.3.2 Term 术语

NO.	Term	Definition (local)
1	服务发现	在SOA网络中，客户端自动发现可用服务及其位置的过程。
2	网络拓扑	车辆内部网络节点（ECU）之间的物理或逻辑连接关系。
3	通信矩阵	定义所有ECU之间信号/服务交互关系的配置文件（如ARXML）。
4	防火墙	一种网络安全系统，用于监控和控制网络流量，基于预定义的安全规则允许或阻止数据包。
5	OTA升级	通过网络远程更新车辆软件的功能。

2. System Overview 系统概述

2.1 System Function 系统功能描述

网络通讯子系统是IDC的"信息高速公路"，核心功能包括：

• 车载以太网通信：实现基于SOME/IP的服务导向通信，支持服务发现、发布/订阅、远程过程调用（RPC）。支持DoIP实现高效诊断。

• 无线连接管理：集成Wi-Fi（客户端/热点模式）和蓝牙（经典蓝牙/BLE），支持与移动设备、外设及基础设施的连接。

• 蜂窝网络通信：集成4G/5G模块，提供广域网连接，支持远程信息处理、紧急呼叫（eCall）、OTA升级及实时数据服务。

• 网络管理与路由：管理复杂的车内网络拓扑（VLAN划分、路由表），实现网络节点的状态监控、唤醒、休眠协同。

• 网络安全：实施多层安全防护，包括防火墙、入侵检测/防御系统（IDS/IPS）、通信加密（TLS/DTLS）、安全启动、安全OTA等。

• 网络诊断与日志：提供丰富的网络状态监控、故障诊断和通信日志记录功能。

2.2 System Block Diagram 系统框图

    +----------------------------------+
    |       应用层 (Apps/Services)      |
    +----------------+-----------------+
                     |
    +----------------v-----------------+
    |    中间件层 (SOME/IP, DDS, MQTT)   |
    +----------------+-----------------+
                     |
    +----------------v-----------------+
    |      网络协议栈 (TCP/IP, UDP)      |
    +-------+--------+--------+--------+
            |        |        |
    +-------v----+ +-v------+ +-v-------+
    | 以太网驱动 | | Wi-Fi  | | 蜂窝网  |
    | & TSN     | | /蓝牙   | | (4G/5G) |
    +-----------+ +--------+ +---------+
            |           |          |
    +-------v-----------+----------v----+
    |           物理层与硬件             |
    |   (以太网PHY, Wi-Fi/BT芯片, 调制解调器) |
    +-----------------------------------+

2.3 Operational environment 运行环境

• 硬件环境：车载以太网交换机/控制器、Wi-Fi/蓝牙组合芯片、4G/5G调制解调器、SIM卡槽、各类天线。

• 软件环境：基于Linux/QNX的网络协议栈，AUTOSAR或自适应AUTOSAR通信栈，Android网络服务框架。

• 外部网络：车内其他ECU（通过以太网/CAN），互联网（通过蜂窝或Wi-Fi），用户移动设备，路边单元（RSU）等。

2.4 System Assumptions 系统假设

• 车辆网络硬件（交换机、线束）符合设计规范且工作正常。

• 蜂窝网络运营商服务在目标市场可用。

• 网络安全证书和密钥管理系统（KMS）已就位。

3. Functional Requirements 功能需求

3.1 需求用例

*(主要用例：应用通过SOME/IP调用服务、诊断仪通过DoIP连接、手机通过Wi-Fi连接车机、车辆通过4G/5G上传数据、防火墙阻止恶意流量)*

3.2 需求矩阵

需求编号	Lv1功能	Lv2功能	功能描述	平台A	平台B
Net_SwRD1001	以太网通信	SOME/IP服务框架	实现完整的SOME/IP协议栈，支持服务发现、事件通知、方法调用	●	●
Net_SwRD1002	以太网通信	DoIP服务端	实现DoIP协议服务端，支持通过以太网进行UDS诊断	●	●
Net_SwRD1003	以太网通信	TSN支持	支持时间敏感网络（TSN）的优先级、流量整形等特性，确保关键流量低延迟	●	-
Net_SwRD2001	无线通信	Wi-Fi连接	支持Wi-Fi STA（连接热点）和AP（创建热点）模式，支持WPA2/WPA3安全协议	●	●
Net_SwRD2002	无线通信	蓝牙连接	支持蓝牙5.0+，支持经典蓝牙（A2DP, HFP, PBAP）和低功耗蓝牙（BLE）	●	●
Net_SwRD3001	蜂窝网络	4G/5G数据连接	集成4G/5G调制解调器，支持多APN配置，提供稳定的移动数据连接	●	●
Net_SwRD3002	蜂窝网络	紧急呼叫(eCall)	支持基于4G/5G的eCall功能，在发生事故时自动或手动发起紧急呼叫并发送MSD	●	●
Net_SwRD4001	网络管理	VLAN配置与管理	支持基于端口的VLAN划分，实现不同网络域（座舱、智驾、车身）的逻辑隔离	●	●
Net_SwRD4002	网络管理	网络状态监控	实时监控各网络接口状态、连接质量、流量统计，并上报异常	●	●
Net_SwRD5001	网络安全	防火墙	实现基于iptables或类似机制的防火墙，可配置规则过滤网络流量	●	●
Net_SwRD5002	网络安全	通信加密	对SOME/IP、DoIP、蜂窝数据等关键通信信道实施TLS/DTLS加密	●	●
Net_SwRD5003	网络安全	入侵检测(IDS)	监控网络流量模式，检测并上报潜在的恶意行为或攻击尝试	●	-
Net_SwRD6001	诊断与日志	网络诊断服务	提供UDS诊断服务，用于读取网络配置、状态、统计信息和清除故障码	●	●
Net_SwRD6002	诊断与日志	通信报文记录	支持按需抓取并存储指定端口的网络通信报文（如PCAP格式），用于问题分析	●	●

3.3 系统框架

网络通讯子系统采用模块化分层架构：

• 硬件抽象层：提供对以太网MAC、Wi-Fi/BT芯片、蜂窝调制解调器的统一驱动接口。

• 网络协议栈层：实现标准TCP/IP协议栈，集成SOME/IP、DoIP等车用协议。

• 网络服务层：提供连接管理、服务发现、安全策略实施、网络监控等高级功能。

• 策略与管理层：提供配置接口、诊断接口、OTA升级管理等。

• 应用适配层：为上层应用提供网络API（如Android ConnectivityManager）。

3.4 需求描述

3.4.1 SOME/IP服务框架 (Net_SwRD1001)

属性	内容
概述/Overview	实现符合AUTOSAR Adaptive标准的SOME/IP（Scalable service-Oriented MiddlewarE over IP）通信中间件，为车内基于服务的架构（SOA）提供核心通信能力，包括服务发现、远程方法调用（RPC）、事件发布/订阅等。
适用平台	所有平台
输入/Input	1. 服务描述文件 ：ARXML格式的服务接口定义，包含服务、方法、事件、字段等。 2. 应用请求 ：上层应用对服务的方法调用请求或事件订阅请求。 3. 网络报文：通过以太网接收到的SOME/IP协议数据单元（PDU）。
处理过程/Process	1. 服务配置与初始化 ：系统启动时，加载ARXML服务描述文件，根据配置实例化服务提供者（Server）和消费者（Client），并注册到SOME/IP中间件。 2. 服务发现（SD） ： a. 服务提供者周期性地多播OfferService报文，宣告其服务可用。 b. 服务消费者发送FindService报文寻找所需服务，或监听OfferService。 c. 发现完成后，消费者获知提供者的单播地址和端口，建立TCP或UDP连接。 3. 远程过程调用（RPC） ：消费者发起方法调用请求（REQUEST），中间件将其序列化为SOME/IP报文发送给提供者。提供者处理请求后，返回响应（RESPONSE）或错误（ERROR）。 4. 事件发布/订阅 ：消费者订阅特定事件。当事件状态改变时，提供者主动向所有订阅者发送包含事件数据的NOTIFICATION报文。 5. 序列化/反序列化：中间件负责根据ARXML定义，对复杂数据类型进行序列化和反序列化。
输出/Output	1. 发送到以太网的SOME/IP协议报文。 2. 向上层应用交付的方法调用结果或事件通知。
性能要求/Performance	方法调用端到端延迟（应用层到应用层）：< 10ms（车内局域网内）。 事件通知延迟：< 5ms。 支持并发服务实例数：≥ 50。
对运行环境的依赖和影响/Impact and dependence	依赖 ：稳定的车载以太网连接；准确的ARXML服务描述。 影响：SOA架构的核心，其性能直接影响座舱内功能调用的响应速度。复杂的序列化可能占用CPU资源。
验证标准/Verification criteria	1. 服务提供者和消费者能正确完成服务发现。 2. 远程方法调用能成功执行并返回正确结果。 3. 事件订阅者能及时收到状态变化通知。 4. 通信符合AUTOSAR SOME/IP协议规范。
验证方法/Verification Method	1. 协议一致性测试 ：使用SOME/IP测试工具（如COVESA vsomeip的测试套件）验证协议实现的正确性。 2. 功能集成测试 ：创建测试服务和客户端，验证完整的服务发现、调用、通知流程。 3. 性能测试：使用压力测试工具模拟大量并发服务调用，测量延迟和吞吐量。
可行性/Feasibility	可行。有开源实现（如COVESA vsomeip）和商业解决方案（如Vector MICROSAR Adaptive）可供参考或集成。
可验证性/Verifiability	高度可验证。网络报文和行为符合标准，易于抓包和分析。
需求分配/Distribution	系统设计 ：SYE，SOA架构团队（定义服务接口ARXML）。 软件实现：SOME/IP中间件集成与配置团队。

3.4.2 DoIP服务端 (Net_SwRD1002)

属性	内容
概述/Overview	实现基于ISO 13400标准的DoIP（Diagnostic over IP）协议服务端，使外部诊断工具能够通过车载以太网（代替传统CAN）对IDC及网关后的其他ECU执行高速、高效的UDS诊断。
适用平台	所有平台
输入/Input	1. 诊断请求 ：来自诊断工具的DoIP报文，封装了UDS诊断服务请求（如0x22读取数据）。 2. 车辆信息：车辆识别码（VIN）、逻辑地址、车型信息等，用于车辆声明和识别。
处理过程/Process	1. 协议初始化与车辆声明 ： a. 系统启动后，DoIP服务端监听标准端口（13400）。 b. 主动发送车辆声明报文（包含VIN、逻辑地址等）到诊断网络，或响应路由激活请求。 2. 连接建立 ：与诊断工具完成TCP连接建立和DoIP会话激活。 3. 报文路由与处理 ： a. 接收到封装了UDS请求的DoIP报文后，解析出目标ECU地址和UDS服务数据。 b. 如果目标地址是IDC自身，则交给本地的UDS诊断协议栈处理。 c. 如果目标地址是其他ECU，则通过车内网络（如CAN网关）将UDS请求转发到对应ECU，并等待响应。 4. 响应返回 ：将UDS诊断响应重新封装进DoIP报文，通过TCP连接发回给诊断工具。 5. 连接保活与超时：管理诊断连接的保活机制，超时后自动关闭连接释放资源。
输出/Output	1. 发送到诊断工具的DoIP响应报文。 2. 转发到车内其他ECU的UDS诊断请求。
性能要求/Performance	TCP连接建立时间：< 2秒。 UDS请求转发与响应的端到端延迟：< 100ms（目标ECU响应正常的情况下）。 支持最大并发诊断连接数：≥ 3。
对运行环境的依赖和影响/Impact and dependence	依赖 ：车载以太网物理连接正常；车内网关支持DoIP到CAN的诊断路由。 影响：大幅提升诊断数据吞吐量，是支持新型高数据量诊断（如软件刷写、大数据量读取）的基础。需要占用网络带宽和系统资源。
验证标准/Verification criteria	1. 使用标准诊断工具（如ODIS， Vector CANdela）能通过以太网成功连接并识别到车辆。 2. 能成功对IDC自身执行读写DTC、读写数据等基本UDS操作。 3. 能通过IDC成功路由诊断请求到指定的远程ECU并获取正确响应。
验证方法/Verification Method	1. 协议测试 ：使用DoIP测试工具（如Vector CANoe的DoIP选项）验证协议实现的合规性。 2. 端到端诊断测试 ：使用真实诊断仪，执行完整的诊断流程，验证功能正确性和性能。 3. 压力测试：模拟多诊断工具并发连接和大数据量诊断请求，验证服务端的稳定性。
可行性/Feasibility	可行。DoIP是成熟标准，有成熟的协议栈可供集成（如Vector DaVinci工具链生成的代码）。
可验证性/Verifiability	高度可验证。诊断交互过程明确，结果可预期。
需求分配/Distribution	系统设计 ：SYE，诊断团队（定义诊断路由表和车辆信息）。 软件实现：DoIP协议栈集成团队，诊断路由服务开发。

3.4.3 Wi-Fi连接管理 (Net_SwRD2001)

属性	内容
概述/Overview	提供完整的Wi-Fi连接管理功能，使车辆既能作为客户端连接外部Wi-Fi热点（如家庭、公共热点），也能作为热点为车内乘客设备提供网络接入。支持最新的安全协议和便捷的连接方式。
适用平台	所有平台
输入/Input	1. 用户操作 ：通过中控屏HMI选择要连接的热点或配置车载热点。 2. 扫描结果 ：Wi-Fi驱动扫描到的周围可用热点列表（SSID, 信号强度, 安全类型）。 3. 认证信息：用户输入的热点密码，或通过WPS、二维码等方式获取的凭据。
处理过程/Process	1. STA模式（客户端） ： a. 扫描与列表 ：周期性地或在用户请求时扫描周围Wi-Fi网络，将结果提供给HMI显示。 b. 连接建立 ：用户选择热点并输入密码（如需要）后，系统调用wpa_supplicant或类似后台服务，执行802.11关联、认证（WPA2/WPA3）、DHCP获取IP地址等流程。 c. 连接管理 ：支持保存多个热点配置，支持自动重连到已知且信号最好的网络。管理连接优先级。 2. AP模式（热点） ： a. 热点配置 ：用户可设置热点SSID、密码（WPA2 PSK）、最大连接数等。 b. 服务启动 ：启动hostapd服务，创建软AP。配置DHCP服务器为连接的设备分配IP地址。 c. 客户端管理 ：显示已连接的设备列表，支持黑名单/白名单管理。 3. 并发模式 ：部分硬件支持并发STA+AP模式，允许车辆同时连接外部网络并提供热点。 4. WPS/二维码连接：支持通过WPS按钮或扫描二维码简化连接流程。
输出/Output	1. STA模式下：获取到的IP地址、网关等网络配置，并建立有效的互联网连接。 2. AP模式下：为连接的客户端设备提供网络接入服务。 3. 连接状态通知（已连接、正在连接、断开等）。
性能要求/Performance	Wi-Fi扫描周期：可配置，默认30秒。 STA模式连接建立时间（输入密码后）：< 10秒。 AP模式启动时间：< 5秒。
对运行环境的依赖和影响/Impact and dependence	依赖 ：Wi-Fi天线性能良好；外部热点兼容主流安全协议。 影响：是提供车内互联网接入和与移动设备互联的主要方式之一。Wi-Fi功耗相对较高，需合理管理。
验证标准/Verification criteria	1. 能成功扫描并列出周围Wi-Fi网络。 2. 能成功连接至使用WPA2/WPA3安全协议的家庭路由器，并访问互联网。 3. 车载热点功能正常，手机等设备能成功连接并通过车机共享的网络上网（如果车机有数据连接）。
验证方法/Verification Method	1. 兼容性测试 ：使用多种品牌、型号的路由器（不同安全设置）测试STA连接功能。 2. 客户端测试 ：使用多种手机、平板设备测试连接车载热点的功能。 3. 性能测试：使用iPerf等工具测试Wi-Fi连接的吞吐量和稳定性。
可行性/Feasibility	可行。Linux/Android有成熟的Wi-Fi管理框架（如wpa_supplicant, hostapd, ConnectivityManager）。
可验证性/Verifiability	高度可验证。连接状态和网络可达性可直接测试。
需求分配/Distribution	系统设计 ：SYE，HMI团队（定义Wi-Fi设置界面）。 软件实现：网络服务团队（集成wpa_supplicant/hostapd，开发管理逻辑）。

3.4.4 蜂窝网络与eCall (Net_SwRD3001 & Net_SwRD3002)

属性	内容
概述/Overview	集成4G/5G蜂窝通信模块，为车辆提供广域网连接能力，支持数据服务和紧急呼叫（eCall）功能。数据连接用于远程信息处理、OTA、实时服务等；eCall用于在发生严重事故时自动或手动联系紧急服务中心。
适用平台	所有平台
输入/Input	数据连接 ：APN配置、网络注册状态、用户数据请求。 eCall触发 ：安全气囊爆破信号（自动）、用户手动按下紧急按钮（SOS）。 MSD数据：车辆位置（GNSS）、VIN、时间、乘员数量（估算）等最小化数据集。
处理过程/Process	蜂窝数据连接 (Net_SwRD3001) ： 1. 模块初始化 ：系统启动后，通过AT命令或QMI/ MBIM协议初始化调制解调器，插入并识别SIM卡。 2. 网络注册 ：自动搜索并注册到可用的蜂窝网络（4G/5G）。 3. PDP上下文激活 ：根据配置的APN（如internet、tsp）建立数据承载，获取IP地址。 4. 连接管理 ：维护数据连接的稳定性，支持网络切换（如5G到4G）、断线重连。支持多APN并发，为不同服务（娱乐、TSP、OTA）分配不同承载。 5. 数据路由 ：将通过蜂窝网络接收到的数据包路由到内部相应服务。 紧急呼叫eCall (Net_SwRD3002) ： 1. 触发检测 ：持续监控来自安全域（通过CAN）的碰撞信号和来自HMI的SOS按钮事件。 2. 紧急会话建立 ：当触发时，立即中断普通数据业务（如果正在使用），通过调制解调器建立到预设紧急号码（如112）的语音通道，同时建立到紧急服务中心（PSAP）的数据通道（如果支持MSD数据通道）。 3. MSD发送 ：通过数据通道或带内调制（如3GPP定义的in-band modem）将包含车辆位置、VIN等信息的MSD发送给PSAP。 4. 语音通话建立 ：建立与PSAP操作员的语音通话，允许车内乘员与操作员沟通。 5. 会话结束：在紧急情况解除后，由操作员或车辆（根据超时）结束紧急呼叫会话。
输出/Output	数据连接 ：可用的互联网IP连接。 eCall：建立的紧急语音通话和已发送的MSD数据。
性能要求/Performance	从开机到建立蜂窝数据连接的时间：< 30秒。 eCall触发到建立语音通话的延迟：< 5秒。 MSD数据应在语音通话建立后10秒内成功发送。
对运行环境的依赖和影响/Impact and dependence	依赖 ：有效的SIM卡和蜂窝网络覆盖；GNSS定位可用（用于MSD中的位置）。 影响：蜂窝连接是车辆实现网联化的根本。eCall是法规要求的生命安全功能，可靠性要求极高。蜂窝模块功耗较大。
验证标准/Verification criteria	1. 车辆在户外能成功注册到4G/5G网络并建立稳定的数据连接，可访问互联网。 2. 模拟碰撞信号或按下SOS按钮，车辆能自动拨打预设的紧急号码，并成功发送MSD数据（在支持PSAP的测试环境下验证）。 3. 在信号边缘区域测试连接稳定性和eCall触发成功率。
验证方法/Verification Method	1. 网络兼容性测试 ：在不同运营商、不同网络制式（SA/NSA）下测试数据连接功能。 2. eCall一致性测试 ：使用eCall测试设备（如Rohde & Schwarz CMW500）或与PSAP测试平台对接，验证协议合规性和端到端功能。 3. 实车路测：在真实网络环境下长时间路测，验证连接的稳定性和eCall功能的可靠性。
可行性/Feasibility	可行。蜂窝模块供应商通常提供完整的驱动和协议栈。eCall是成熟法规要求功能，有成熟的解决方案。
可验证性/Verifiability	高度可验证。数据连接可测试，eCall功能可通过专业测试设备验证。
需求分配/Distribution	硬件 ：蜂窝调制解调器选型与集成。 软件实现：蜂窝调制解调器驱动与协议栈集成，eCall协议栈与安全气囊接口集成。

3.4.5 VLAN配置与管理 (Net_SwRD4001)

属性	内容
概述/Overview	在车载以太网交换机上实现基于端口的虚拟局域网（VLAN）划分，将单一物理网络划分为多个逻辑上隔离的广播域，以满足整车不同功能域（如座舱娱乐、智能驾驶、车身控制）对网络安全、流量隔离和性能的不同需求。
适用平台	所有平台
输入/Input	1. 网络拓扑配置 ：预定义的VLAN规划表，指定每个交换机端口所属的VLAN ID（VID），以及端口类型（Access或Trunk）。 2. 动态配置指令：通过网络管理协议或本地命令进行的运行时VLAN配置更新（如诊断或OTA后更新）。
处理过程/Process	1. 静态配置加载 ：系统启动时，网络管理服务从非易失存储器读取VLAN配置表，通过交换机管理接口（如MDIO, SPI）将配置写入交换芯片的寄存器。 2. 端口VLAN配置 ： a. Access端口 ：分配给一个特定的VLAN。从该端口进入的报文被打上该VLAN的标签（在芯片内部），从该端口发出的报文则剥离VLAN标签。通常用于连接终端ECU。 b. Trunk端口 ：允许多个VLAN的报文通过。报文保留VLAN标签。通常用于交换机之间的级联或连接需要处理多个VLAN的域控制器（如IDC）。 3. VLAN路由/桥接 ：在IDC内部（如果作为网关），需要配置虚拟网络接口（如eth0.10, eth0.20）对应不同的VLAN，并可能在这些VLAN接口之间根据策略进行路由或桥接。 4. 配置持久化与验证 ：配置成功后需保存并验证。提供接口查询当前VLAN配置状态。 5. 安全隔离：确保不同VLAN之间的广播流量被隔离，未经路由/防火墙规则允许，不能直接通信。
输出/Output	1. 交换机芯片内的VLAN配置状态。 2. IDC操作系统内对应的虚拟网络接口。
性能要求/Performance	VLAN配置应在系统启动后网络初始化阶段完成，总耗时 < 2秒。 VLAN标签处理在硬件交换机中进行，不应引入额外的数据转发延迟。
对运行环境的依赖和影响/Impact and dependence	依赖 ：车载以太网交换机支持VLAN功能；网络拓扑设计正确。 影响：是实现整车E/E架构网络逻辑隔离、保障功能安全和网络安全的基础。错误的VLAN配置可能导致网络不通或安全漏洞。
验证标准/Verification criteria	1. 根据配置表，使用网络测试仪或发包工具验证：同一VLAN内的ECU可以互相通信，不同VLAN的ECU默认不能直接通信。 2. 验证Trunk端口能正确转发带有多VLAN标签的报文。 3. 验证配置在重启后能正确恢复。
验证方法/Verification Method	1. 网络抓包分析 ：在Trunk端口上抓包，检查报文是否带有正确的VLAN标签。 2. 连通性测试 ：编写脚本，从属于不同VLAN的测试节点互相ping，验证隔离效果。 3. 配置注入测试：尝试注入错误或冲突的VLAN配置，验证系统的错误处理和恢复能力。
可行性/Feasibility	可行。主流车载以太网交换机芯片（如Marvell, Broadcom）均支持VLAN，且Linux网络栈有成熟的VLAN支持（802.1Q）。
可验证性/Verifiability	高度可验证。配置和通信行为可以通过网络工具明确验证。
需求分配/Distribution	系统设计 ：SYE，网络架构团队（定义整车VLAN规划）。 软件实现：BSP/网络驱动团队（实现交换机配置管理）。

3.4.6 网络状态监控 (Net_SwRD4002)

属性	内容
概述/Overview	实现对智能座舱域控制器所有活跃网络接口（如车载以太网、Wi-Fi STA/AP、蜂窝网络）的状态、连接质量及流量数据的实时监控与采集。系统应能主动检测异常（如链路中断、高延迟、高丢包率），并将监控数据、统计信息及异常事件上报给上层网络管理服务或诊断系统，为网络健康度评估、故障排查和用户体验优化提供数据支撑。
适用平台	所有平台
输入/Input	1. 底层驱动数据 ：从网络驱动和协议栈获取的各接口链路状态（UP/DOWN）、MAC地址、IP地址、子网掩码、网关等。 2. 内核统计信息 ：通过 netstat、ss、ip -s link 或 /proc/net/dev、/sys/class/net/ 等接口获取的实时流量统计（收发包数、字节数、错误数、丢包数）。 3. 主动探测结果 ：周期性对关键网关或服务（如T-Box、云端服务器）执行Ping（ICMP）或TCP连接测试，获取往返延迟（RTT）和丢包率。 4. 无线信号数据 ：从Wi-Fi驱动获取的接收信号强度指示（RSSI）、信噪比（SNR）、连接速率等。 5. 蜂窝网络信息：从调制解调器获取的运营商名称、网络类型（4G/5G）、信号强度（RSRP/RSRQ）、小区ID等。
处理过程/Process	1. 数据采集与聚合 ： a. 启动独立的监控守护进程，以可配置的周期（如1秒、5秒）轮询或订阅事件，从上述输入源收集原始数据。 b. 对流量数据计算周期内的速率（bps, pps）。 c. 将数据与接口标识、时间戳关联，形成结构化记录。 2. 状态分析与异常检测 ： a. 基础状态 ：判断接口物理链路状态（UP/DOWN）和管理状态。 b. 性能阈值 ：将延迟、丢包率、错误包计数与预设阈值比较。例如，连续3次Ping延迟 > 100ms 或丢包率 > 5% 判定为"质量劣化"。 c. 变化检测 ：监控IP地址、网关、DNS等关键配置的变更。 d. 无线质量 ：根据RSSI划分信号等级（优/良/中/差）。 3. 事件上报与日志记录 ： a. 当检测到异常（如链路断开、性能超标）时，立即生成事件，通过D-Bus、SOME/IP事件或系统日志上报给网络管理模块和诊断事件管理器。 b. 所有异常事件需包含时间、接口、异常类型、严重等级和关键测量值。 c. 周期性地将聚合后的性能统计信息（如每分钟平均流量、最高延迟）记录到循环缓冲区或文件中，供历史查询。 4. 数据暴露与查询 ： a. 提供D-Bus或SOME/IP服务接口，供HMI（网络状态页面）、诊断工具或其他服务实时查询当前各接口的详细状态和统计信息。 b. 支持通过UDS诊断服务（如 0x22 读取数据）获取关键监控数据。
输出/Output	1. 实时状态数据 ：各网络接口的详细状态对象，包含连接状态、IP信息、信号强度（无线）、实时上下行速率等。 2. 异常事件通知 ：标准化格式的网络异常事件消息，用于触发仪表盘警告图标、日志记录或远程告警。 3. 历史统计日志 ：时间序列格式的网络性能日志，可用于离线分析网络质量趋势。 4. 诊断数据：可通过诊断接口读取的网络健康度快照。
性能要求/Performance	1. 采集延迟 ：从物理事件发生（如网线拔出）到监控进程感知并更新状态 ≤ 2秒。 2. 数据更新周期 ：流量统计与性能数据更新周期可配置，最短支持1秒间隔。 3. 系统开销 ：监控服务整体CPU占用率（在1秒采样周期下）< 3%，内存占用 < 50MB。 4. 存储要求：历史统计日志在车辆上至少保留最近7天的数据。
对运行环境的依赖和影响/Impact and dependence on the operating environment	依赖 ： 1. 操作系统内核提供准确、稳定的网络设备统计信息接口。 2. 拥有对网络命名空间和配置进行读取的权限。 影响 ： 1. 正面 ：极大提升网络问题的可观测性和定位效率，是实现智能运维和体验保障的基础。 2. 负面：高频的数据采集和计算会消耗一定的CPU和内存资源。配置不当的主动探测（如Ping频率过高）可能增加网络负担。
验证标准/Verification criteria	1. 功能完整性 ：HMI网络设置页面能正确显示所有接口的实时状态、IP、信号强度和流量曲线。 2. 异常检测准确性 ：模拟网线拔出、Wi-Fi断开、制造高延迟网络环境，系统均能在规定时间内产生正确等级和内容的异常事件。 3. 数据准确性 ：使用第三方抓包工具（如Wireshark）统计的流量数据，与系统监控服务提供的数据误差 < 2%。 4. 接口可用性：诊断工具能通过UDS服务成功读取到网络接口的状态和统计信息。
验证方法/ Verification Method	1. 台架模拟测试 ：在网络测试仪或模拟环境中，动态制造各种网络异常场景，验证监控系统的检测和上报能力。 2. 数据对比测试 ：在IDC的监控端口进行流量镜像，同时用Wireshark和系统监控服务统计流量，对比结果。 3. HMI集成测试 ：操作车辆，在各种网络环境下观察HMI状态页的显示是否实时、准确。 4. 诊断接口测试：使用诊断仪调用相关DID，验证数据读取功能。
可行性/Feasibility	可行。Linux内核提供了丰富的网络统计和配置接口（netlink， sysfs， procfs）。主要的开发工作在于数据采集框架的搭建、阈值判断逻辑的实现以及与上层服务（HMI、诊断）的集成。
可验证性/Verifiability	高度可验证。所有监控数据均可通过外部工具进行交叉验证，异常场景可以精确模拟和复现。
需求分配/Distribution	系统设计 ：定义监控指标、阈值、事件格式及上报接口（系统部）。 软件开发 ：实现监控守护进程、数据采集器、分析引擎和对外服务接口（应用软件部）。 HMI开发 ：开发用于展示监控数据的界面（HMI部）。 测试验证：设计并执行异常场景测试和数据准确性测试（测试部）。

---

3.4.7 防火墙 (Net_SwRD5001)

属性	内容
概述/Overview	在IDC的Linux/QNX操作系统内核中，部署基于netfilter/iptables或nftables的包过滤防火墙。该防火墙作为网络安全的第一道防线，依据预定义的安全策略（规则集），对进出所有网络接口（以太网、Wi-Fi、蜂窝）的数据包进行实时检查、过滤和日志记录，实现访问控制，阻止未授权的网络访问和已知的恶意流量。
适用平台	所有平台
输入/Input	1. 安全策略配置 ：由系统安全架构师定义的防火墙规则集文件（如iptables规则脚本），明确允许/拒绝流量的源/目的IP、端口、协议等。 2. 实时网络数据包 ：流经网络协议栈的每一个IP数据包。 3. 动态更新指令 ：来自安全管理服务的指令，用于在运行时临时添加/删除规则（如为特定诊断会话开放端口）。 4. 车辆状态：车辆电源模式（如运行、休眠），用于切换不同安全等级的规则集。
处理过程/Process	1. 策略加载与初始化 ： a. 系统启动时，防火墙服务根据车辆配置和当前模式，加载对应的基础规则集到内核netfilter框架。 b. 默认策略应设置为"拒绝所有"（DROP），然后按需添加允许（ACCEPT）规则，遵循最小权限原则。 2. 包过滤流程（遵循规则链） ： a. 入口过滤（INPUT链） ：检查目的地为本机（IDC）的入站数据包。例如，仅允许来自可信ECU（如网关）的SOME/IP服务发现端口（30490）流量，拒绝外部对管理端口的访问。 b. 出口过滤（OUTPUT链） ：检查由本机发出的出站数据包。控制IDC主动发起的连接。 c. 转发过滤（FORWARD链） ：如果IDC充当路由器（如Wi-Fi热点模式），检查需要转发的数据包。严格隔离车内网（以太网）与用户设备网（Wi-Fi客户端）。 d. 规则按顺序匹配，匹配即执行对应动作（ACCEPT， DROP， LOG）。 3. 日志记录与告警 ： a. 对匹配了LOG规则或默认DROP策略的数据包（尤其是被拒绝的访问尝试），记录其关键信息（时间戳、协议、源/目的、端口）到安全日志。 b. 高频的非法访问尝试应触发安全事件告警。 4. 规则动态管理 ： a. 提供安全的本地或远程管理接口（需严格认证授权），用于应急响应和策略更新。 b. 任何对永久规则集的修改，都必须经过签名验证，并在重启后能持久化生效。
输出/Output	1. 过滤结果 ：允许通过或丢弃的网络数据包。 2. 安全审计日志 ：记录被拒绝和特定被允许的连接的详细条目，用于事后分析和取证。 3. 安全事件：针对疑似扫描、暴力破解等攻击模式产生的告警事件。
性能要求/Performance	1. 吞吐量影响 ：启用防火墙后，对网络最大吞吐量的衰减应 < 5%。 2. 延迟影响 ：防火墙规则处理对数据包转发的额外延迟应 < 100 µs。 3. 规则容量 ：系统应能高效处理不少于500条过滤规则。 4. 启动时间：基础规则集加载并生效的时间应 < 5秒。
对运行环境的依赖和影响/Impact and dependence on the operating environment	依赖 ： 1. 操作系统内核支持并已启用netfilter框架。 2. 安全团队提供正确、完整、无冲突的防火墙规则集。 影响 ： 1. 正面 ：显著提升系统对网络层攻击（如端口扫描、未授权访问）的防御能力，是满足UNECE R155法规中"防御纵深"要求的关键组件。 2. 负面：配置错误的规则可能导致合法业务通信中断，引发严重功能故障。规则匹配消耗CPU资源。
验证标准/Verification criteria	1. 默认拒绝 ：在仅加载基础规则集后，从非白名单IP或端口发起的所有访问均应被拒绝。 2. 业务连通性 ：在防火墙启用状态下，所有设计内的车内通信（SOME/IP， DoIP）、用户服务（Wi-Fi热点上网）和远程服务（TSP连接）均能正常进行。 3. 攻击防御 ：模拟外部攻击（如NMAP全端口扫描、SYN洪水攻击），防火墙应能有效阻断并产生相应日志。 4. 性能达标：通过性能测试工具验证，防火墙开启前后，网络吞吐量和延迟满足要求。
验证方法/ Verification Method	1. 渗透测试/模糊测试 ：由安全测试团队使用专业工具（如Metasploit, Kali Linux套件）从各个网络接口发起攻击，验证防护效果。 2. 功能连通性测试 ：在台架上，逐一验证所有依赖网络的业务功能在防火墙启用后是否正常。 3. 规则验证测试 ：编写测试脚本，模拟设计内的各种合法流量，确保其能匹配正确的ACCEPT规则；模拟非法流量，确保其被DROP。 4. 性能压测 ：使用iperf3、trex等工具，在高流量压力下测量防火墙的性能损耗。
可行性/Feasibility	可行。iptables/nftables是Linux内核的标准功能，技术极为成熟。挑战在于为复杂的车载SOA环境设计一套正确、精简且高效的规则集，这需要深入的网络架构和业务流知识。
可验证性/Verifiability	高度可验证。防火墙的行为（允许/拒绝）可以通过发送测试报文直接观测；日志提供了明确的操作记录；性能可以量化测量。
需求分配/Distribution	网络安全架构 ：设计整体的防火墙策略和规则集（网络安全部）。 系统集成 ：负责防火墙服务的启动脚本、规则集部署和基础配置（系统集成部）。 BSP/内核 ：确保内核配置已支持所需netfilter模块（底层软件部）。 测试：执行渗透测试和功能连通性测试（安全测试部、系统测试部）。

---

3.4.8 通信加密 (Net_SwRD5002)

属性	内容
概述/Overview	为车载网络中传输的敏感数据提供端到端或节点到节点的机密性与完整性保护。通过对SOME/IP服务通信、DoIP诊断会话以及经蜂窝网络传输的TSP/OTA数据等关键信道实施基于TLS（传输层安全）或DTLS（数据报TLS）的加密，防止数据在传输过程中被窃听、篡改或重放攻击，满足网络安全法规（如R155）和个人信息保护要求。
适用平台	所有平台
输入/Input	1. 待发送的明文应用数据 ：来自SOME/IP服务、诊断服务、远程信息处理应用的有效载荷。 2. 安全证书与密钥 ： a. 实体证书 ：IDC自身的身份证书，由车辆或组件证书颁发机构（CA）签发。 b. 信任根证书 ：用于验证对端（如TSP服务器、诊断仪、其他ECU）证书的CA根证书。 c. 私钥 ：与IDC实体证书配对的私钥，需安全存储（如HSM， TPM， 安全芯片）。 3. 通信对端信息 ：目标服务的IP地址、端口及预期的服务器名称指示（SNI）。 4. 加密策略配置：定义哪些服务/端口必须使用加密、支持的TLS版本（如1.2， 1.3）、加密套件列表等。
处理过程/Process	1. TLS/DTLS连接建立 ： a. 客户端模式 （如IDC连接TSP）：发起ClientHello，在ServerHello后验证服务器证书链的有效性（是否由可信CA签发、是否在有效期内、主机名匹配）。协商会话密钥。 b. 服务器模式 （如提供加密的SOME/IP服务）：监听端口，接收ClientHello，发送自身证书供客户端验证，完成握手。 2. 数据加密传输 ： a. 握手成功后，应用层数据在送入TCP（TLS）或UDP（DTLS）套接字前，由TLS/DTLS库进行加密和完整性签名（MAC）。 b. 接收端对数据包进行解密和完整性校验，将明文交付给上层应用。 3. 会话管理 ： a. 支持会话恢复（Session Resumption）以减少重复握手的开销。 b. 管理会话的生命周期，在空闲超时或错误时关闭连接。 4. 密钥与证书管理 ： a. 安全地存储和访问私钥，防止泄露。 b. 提供证书更新机制，以处理证书过期问题（通常通过安全OTA）。 c. 维护证书吊销列表（CRL）或支持在线证书状态协议（OCSP）以验证证书状态。
输出/Output	1. 加密后的网络数据流 ：通过TCP/UDP传输的密文。 2. 安全的通信信道 ：为上层应用提供的、具备机密性和完整性保障的逻辑连接。 3. 安全审计日志：记录TLS握手成功/失败、证书验证错误、协议版本等信息。
性能要求/Performance	1. 握手延迟 ：完整的TLS 1.3握手（包含证书验证和密钥交换）增加的时间应 < 300ms（在典型车载处理器和网络条件下）。 2. 数据吞吐量影响 ：开启TLS加密后，应用层有效数据吞吐量的下降应 < 15%。 3. CPU与内存开销 ：加解密操作对CPU的额外占用应在可接受范围内（需根据选定的芯片和算法实测）。TLS上下文的内存占用应可控。 4. 并发连接数：支持至少50个并发加密连接。
对运行环境的依赖和影响/Impact and dependence on the operating environment	依赖 ： 1. 稳定可靠的PKI（公钥基础设施）体系，包括CA、证书分发和吊销机制。 2. 硬件支持安全密钥存储（如HSM, TPM）或高性能加解密加速器。 影响 ： 1. 正面 ：是保护车辆数据安全和用户隐私的核心技术，为网联功能提供可信的通信基础，是合规的必要条件。 2. 负面：引入加解密计算开销，增加通信延迟和功耗。证书管理复杂，增加运维成本。
验证标准/Verification criteria	1. 功能正确性 ： a. 使用有效证书，能成功与对端（如测试TSP服务器）建立加密连接并传输数据。 b. 使用无效/过期/吊销的证书或错误的SNI，连接应被拒绝。 2. 安全性 ： a. 使用抓包工具（如Wireshark）捕获的通信流量应为不可读的密文（握手过程除外）。 b. 能抵御中间人攻击（测试工具模拟），即证书验证失败应导致连接终止。 3. 互操作性 ：能与符合行业标准的第三方TLS实现（如OpenSSL， wolfSSL）成功互连。 4. 性能达标：握手时间和吞吐量影响满足上述性能要求。
验证方法/ Verification Method	1. 协议测试 ：使用TLS/DTLS测试套件（如tlsfuzzer）或商业协议测试仪，验证协议实现的正确性和健壮性。 2. 渗透测试 ：由安全专家尝试进行降级攻击、弱加密套件攻击等，验证系统配置的安全性。 3. 端到端集成测试 ：搭建包含IDC和模拟TSP服务器的测试环境，验证完整的加密业务流。 4. 性能基准测试 ：使用iperf3等工具，对比相同环境下明文传输和TLS加密传输的性能差异。
可行性/Feasibility	可行。TLS/DTLS是互联网和物联网领域的成熟标准，有众多优秀开源库（如mbed TLS， OpenSSL）可选。主要挑战在于：1）为资源受限的嵌入式环境选择和优化合适的库；2）建立并管理整个车辆生命周期的PKI体系；3）确保私钥的物理安全。
可验证性/Verifiability	可验证。加密信道的建立过程和数据密文可以通过网络抓包观察。安全测试工具可以系统地验证其对抗各种攻击的能力。性能可以量化测试。
需求分配/Distribution	网络安全架构 ：定义加密范围、策略、证书体系和安全要求（网络安全部）。 软件开发 ：集成TLS/DTLS库，实现服务端/客户端加密适配层（应用软件部）。 平台/安全 ：负责HSM/TPM集成、安全启动、密钥注入与管理流程（平台安全部）。 测试：执行协议一致性、安全性渗透和性能测试（安全测试部、性能测试部）。

4. System prototype 系统原型

(略：主要描述在工程模式下用于展示网络状态的原型界面，例如网络拓扑图、各接口状态、连接信息、流量统计、防火墙规则列表等)

5. Interface Requirements 接口需求

5.1 External Interface 外部接口

5.1.1 车载以太网时间同步接口【系统需求】

需求编号	SwRD-IF-EXT-001

属性	内容
概述/Overview	定义智能座舱域控制器（IDC）与车内其他域控制器（如T-Box、CCU、ADC）之间通过车载以太网进行时间同步的物理层与协议层接口。该接口支持gPTP（IEEE 802.1AS）和SOME/IP时间服务，是实现整车高精度时间基准同步的核心通道。
对运行环境的依赖和影响/Impact and dependence on the operating environment	依赖： 1. 车载以太网物理层（100/1000BASE-T1）连接正常；2. 网络交换机支持gPTP硬件时间戳；3. 通信链路无异常干扰。影响： 此接口的稳定性直接影响座舱与智驾、车身等域的时间同步精度，进而影响传感器融合、日志时序分析、音视频同步等高精度时间依赖功能。
验证标准/Verification criteria	1. 物理层：链路自协商成功，双工模式正确，误码率低于10⁻¹²。2. 协议层：gPTP协议栈能正确收发Sync、Follow_Up、Delay_Req、Delay_Resp报文；SOME/IP时间服务可被正常发现与调用。3. 性能：gPTP主从时钟同步精度≤1µs（实验室理想环境）；SOME/IP时间服务调用延迟≤10ms。
验证方法/ Verification Method	1. 物理测试： 使用网络测试仪（如IXIA、Spirent）验证物理链路参数和误码率。2. 协议测试： 使用以太网抓包工具（Wireshark）分析gPTP和SOME/IP报文交互的正确性。3. 集成测试： 搭建包含T-Box（Master）和IDC（Slave）的台架，使用高精度时间戳采集卡测量实际同步误差。
可行性/Feasibility	可行。主流车载以太网控制器（如Marvell 88Q5050, NXP SJA1105）均支持硬件时间戳功能；gPTP和SOME/IP协议栈已有成熟开源（linuxptp, vsomeip）或商业（Vector, Elektrobit）实现。
可验证性/Verifiability	高度可验证。物理层参数和网络报文可被标准工具直接测量与分析。同步精度可通过外部高精度参考时钟进行对比测量。
需求分配/Distribution	硬件： 以太网PHY芯片选型与电路设计（硬件部）。BSP/驱动： 以太网控制器驱动开发，确保硬件时间戳功能使能（底层软件部）。中间件： gPTP协议栈（如linuxptp）移植与配置、SOME/IP时间服务开发（中间件部）。系统集成： 接口定义与整体联调（系统集成部）。

5.2 Internal Interface 内部接口

5.2.1 CarTimeSync服务与系统时钟接口【系统需求】

需求编号	SwRD-IF-INT-001

属性	内容
概述/Overview	定义座舱时间同步核心服务（CarTimeSync）与操作系统内核时钟、硬件RTC之间的软件接口。该接口允许CarTimeSync将仲裁后的权威UTC时间设置到系统内核，并持久化到硬件RTC中，同时从内核获取高精度单调时钟用于频率同步和守时计算。
对运行环境的依赖和影响/Impact and dependence on the operating environment	依赖： 1. 操作系统提供高精度时间设置与查询API（如clock_settime, clock_gettime）；2. 系统内核支持CLOCK_REALTIME和CLOCK_MONOTONIC；3. MCU提供可靠的SPI/I2C接口用于访问外部RTC芯片。影响： 此接口是连接"应用层时间仲裁"与"系统底层计时"的桥梁，其调用延迟和可靠性直接影响所有应用获取时间的精度和一致性。接口故障将导致系统时间错误。
验证标准/Verification criteria	1. 功能性： CarTimeSync能成功调用clock_settime设置系统时间；能通过SPI/I2C读写RTC芯片寄存器。2. 精度： 通过API设置的时间与内核实际生效时间之间的延迟≤10ms。3. 原子性： 时间设置操作是原子的，不会导致系统时间出现中间态（如先改秒再改分）。4. 错误处理： 当RTC访问失败时，应有明确错误码返回和日志记录。
验证方法/ Verification Method	1. API测试： 编写测试程序，模拟CarTimeSync调用时间设置API，并立即读取验证设置结果。2. 延迟测试： 使用高精度示波器或软件跟踪工具，测量从clock_settime调用返回到clock_gettime读取到新值的时间差。3. RTC读写测试： 通过MCU调试接口或逻辑分析仪，抓取SPI/I2C总线波形，验证读写命令和数据的正确性。4. 异常注入： 模拟SPI/I2C总线故障、RTC芯片无响应等场景，验证CarTimeSync的错误处理逻辑。
可行性/Feasibility	可行。clock_settime/gettime是POSIX标准系统调用，所有主流嵌入式OS（QNX, Linux）均支持。访问RTC是标准的嵌入式外设操作，有成熟驱动模型。
可验证性/Verifiability	可验证。系统时间可通过命令行或API直接查询。RTC的读写操作可通过总线分析仪观测。软件调用流程可通过日志和调试工具跟踪。
需求分配/Distribution	系统软件： 定义CarTimeSync服务与内核的调用规范（系统设计部）。底层驱动： 实现或配置RTC芯片的稳定驱动（BSP部）。CarTimeSync开发： 实现调用系统API和RTC驱动的业务逻辑（应用软件部）。

6. Design Constraints 设计约束

6.1 时间源仲裁与切换逻辑约束【系统需求】

属性	内容
概述/Overview	强制规定时间同步系统中多源时间仲裁与切换逻辑的设计必须遵循确定的优先级、滞回和健康度检查机制，以确保时间基准的连续性、稳定性和安全性，避免因源频繁抖动或失效导致系统时间跳变或紊乱。
对运行环境的依赖和影响/Impact and dependence on the operating environment	依赖： 各时间源（GNSS, NTP, gPTP, RTC）能提供有效的健康状态标识。影响： 此约束决定了系统在各种复杂场景（如进出隧道、网络闪断）下的时间行为。设计不当会导致时间频繁跳变，影响上层应用（如导航、媒体播放、事件日志）的体验和可靠性。
验证标准/Verification criteria	1. 优先级固定： 时间源优先级必须为：gPTP > GNSS > NTP > RTC > 手动设置。仅在更高优先级源持续失效（超时）后，才允许切换至低优先级源。2. 滞回要求： 从低优先级源切回高优先级源时，必须满足高优先级源连续稳定时间≥10秒，且与当前系统时间的偏差小于阈值（如100ms）。3. 健康度检查： 必须对所有外部源（gPTP, GNSS, NTP）进行周期性的信号有效性检查（如锁定状态、报文到达间隔）。4. 平滑切换： 当需要校正的时间偏差小于1秒时，应采用adjtime等机制进行微调；大于1秒时，可允许跳变，但必须记录审计日志。
验证方法/ Verification Method	1. 场景模拟测试： 在台架或仿真环境中，模拟各时间源的通、断、抖动场景，验证切换逻辑是否符合优先级和滞回要求。2. 逻辑评审： 对CarTimeSync仲裁状态机的代码或模型进行走查，确认逻辑无歧义。3. 长稳定性测试： 进行72小时以上的持续测试，监控时间源切换次数和系统时间曲线，确保无异常振荡。
可行性/Feasibility	可行。基于状态机的仲裁逻辑在软件上容易实现。难点在于各源健康度指标的准确获取，这需要与T-Box、GNSS模块等供应商明确接口定义。
可验证性/Verifiability	可验证。通过模拟控制各时间源的可用性，可以清晰地触发和观察仲裁状态机的行为。系统日志应详细记录每次切换的原因和时间。
需求分配/Distribution	系统架构： 定义完整的仲裁状态机与切换策略（系统部）。CarTimeSync开发： 实现仲裁状态机（应用软件部）。供应商协同： 与T-Box、GNSS模块供应商确定健康状态上报接口（供应链/产品部）。

7. Quality Requirements 质量需求

7.1 Performance 性能

7.1.1 时间同步精度与保持能力【系统需求】

需求编号	SwRD-QA-PERF-001

属性	内容
概述/Overview	规定智能座舱域控制器在不同时间源可用性场景下，其系统时间相对于权威时间基准（如UTC）的精度要求，以及在外部时间源全部丢失后的时间保持（守时）能力。
对运行环境的依赖和影响/Impact and dependence on the operating environment	依赖： 1. 外部高精度源（gPTP/GNSS）的信号质量；2. 本地晶振（OSC）的频率稳定度；3. 温度、电压等环境因素。影响： 此性能是时间同步系统的核心价值体现，直接影响所有依赖精确时间的上层功能，如日志分析、事故溯源、高精度地图匹配、车路协同等。
验证标准/Verification criteria	1. gPTP同步精度： 在实验室理想网络环境下（无交换机，点对点连接），IDC作为gPTP Slave，其系统时间与Master的时间偏差应 ≤ ±1 µs。2. NTP同步精度： 在良好的4G/5G网络环境下，通过NTP同步的时间偏差应 ≤ ±50 ms。3. 守时能力： 在所有外部时间源（gPTP， GNSS， NTP）均失效后，仅依靠内部RTC和系统时钟守时，要求：- 1小时内，时间累积误差 ≤ ±10 ms。- 24小时内，时间累积误差 ≤ ±500 ms。- 要求基于车载级温补晶振（TCXO）。4. 同步建立时间： 从上电完成到首次通过gPTP成功同步的时间 ≤ 30秒。
验证方法/ Verification Method	1. gPTP精度测试： 使用支持PTP的高精度时间戳测试仪（如思博伦TimeCenter），同时抓取Master和Slave的PTP报文和硬件时间戳，计算偏差。2. NTP精度测试： 在IDC旁路接入高精度GPS时钟（作为参考），与IDC系统时间对比。3. 守时测试： 在台架上，让IDC先与gPTP Master同步，然后物理断开所有时间源网络，持续运行24小时，每小时记录一次与参考时钟的偏差。4. 建立时间测试： 记录从系统启动日志开始到CarTimeSync日志报告首次gPTP同步成功的时间差。
可行性/Feasibility	可行，但挑战在于精度指标的达成依赖于硬件（以太网PHY的硬件时间戳性能、晶振品质）和软件（协议栈优化、中断延迟控制）的共同优化。亚微秒级精度需要精心设计和调优。
可验证性/Verifiability	可验证，但需要专业的测试设备（高精度时间参考源、时间戳测试仪）和严格的测试环境控制（温度、电磁干扰）。
需求分配/Distribution	硬件设计： 选用支持硬件时间戳的高性能以太网PHY和车载级TCXO（硬件部）。BSP/驱动： 优化驱动，确保硬件时间戳中断延迟最小化（底层软件部）。协议栈开发： 优化gPTP协议栈参数和时钟伺服算法（中间件部）。测试验证： 搭建高精度测试环境并执行测试（测试部）。

7.2 Reliability 可靠性

7.2.1 时间同步服务故障恢复【系统需求】

需求编号	SwRD-QA-REL-001

属性	内容
概述/Overview	规定时间同步核心服务（如CarTimeSync进程、gPTP协议栈守护进程）在发生意外崩溃、挂起或资源耗尽等故障后的自动恢复机制与恢复时间目标，确保时间同步功能的高可用性。
对运行环境的依赖和影响/Impact and dependence on the operating environment	依赖： 操作系统的进程监控与管理机制（如systemd, watchdog）。影响： 时间同步服务长时间不可用将导致系统时间逐渐漂移，影响所有时间相关功能，并在问题诊断时造成时间戳混乱。快速恢复是保证系统持续可靠运行的关键。
验证标准/Verification criteria	1. 进程监控： 必须有独立的监控机制（如systemd或看门狗）监控CarTimeSync和gPTP守护进程（如ptp4l）的心跳或存活状态。2. 自动重启： 当监测到关键进程非正常退出时，监控机制应在3秒内自动重启该进程。3. 恢复后状态： 进程重启后，应能自动加载最近的正确配置，并尝试重建与时间源的同步，不应遗留错误状态。4. 最大恢复时间： 从进程崩溃到时间同步功能完全恢复（即重新与高优先级源建立同步）的总时间应 ≤ 60秒。5. 多次重启防护： 若进程在短时间内（如5分钟）连续崩溃超过3次，应停止重启并上报严重错误，进入安全状态（如依赖RTC守时）。
验证方法/ Verification Method	1. 故障注入测试： 在系统运行时，通过kill -9命令强制杀死CarTimeSync或ptp4l进程，观察监控机制是否能正确检测并重启。使用秒表或系统日志记录崩溃到恢复的时间。2. 资源耗尽测试： 人为制造内存泄漏或句柄泄漏，导致进程异常，验证恢复机制。3. 边界测试： 模拟短时间内连续崩溃，验证多次重启防护逻辑是否触发。4. 日志分析： 检查系统日志，确认每次故障、检测、重启、恢复同步的事件记录完整准确。
可行性/Feasibility	可行。利用Linux/QNX的系统服务管理工具（systemd）可以方便地配置进程监控和重启策略。关键在于设计合理的健康检查点和恢复后初始化流程。
可验证性/Verifiability	可验证。通过主动注入故障并观察系统行为，可以明确验证恢复机制的各个环节。系统日志提供了完整的追溯信息。
需求分配/Distribution	系统设计： 定义关键服务列表、监控策略和恢复流程（系统部）。BSP/系统集成： 配置systemd服务单元文件或实现看门狗监控（底层软件/集成部）。CarTimeSync开发： 实现优雅的启动、初始化和状态恢复逻辑（应用软件部）。

8. Implement Requirements 实施需求

• 产线测试：产线需对每个网络接口进行连通性、吞吐量基本测试。写入初始的VIN、证书等。

• 现场配置：运营商SIM卡配置、APN设置可能需要在销售环节完成。

• 诊断集成：需提供完整的网络相关DTC和诊断服务，支持远程诊断和日志提取。

9. Legal Constraints and Standards Compliance 法律约束和标准遵从

• 法规：必须符合目标市场关于电信设备入网、无线电发射（Wi-Fi/蓝牙/蜂窝）、eCall紧急呼叫（如欧盟、俄罗斯、中国）的强制性法规。

• 标准：网络协议实现需遵循相关标准：IEEE 802.3（以太网）、IEEE 802.11（Wi-Fi）、3GPP（蜂窝）、ISO 13400（DoIP）、AUTOSAR（SOME/IP）等。

• 环保：符合RoHS、REACH等环保指令。

10. Related Documents 相关文档【信息】

1. 《整车网络架构设计规范》

2. 《车载以太交换机硬件规格书》

3. 《蜂窝模块接口控制文档（ICD）》

4. 《网络安全概念（Cybersecurity Concept）文档》

5. 《诊断规范》

6. 本项目《时间同步子系统需求&软件需求》

7. 本项目《定位子系统需求&软件需求》