车联网系统运维与故障排除手册

车联网系统运维与故障排除手册第1章系统概述与基础架构1.1车联网系统基本概念车联网（V2X）是指车辆与车辆（V2V）、车辆与基础设施（V2I）、车辆与行人（V2P）以及车辆与互联网（V2I）之间的信息交互系统，其核心目标是提升道路安全、优化交通流量并实现智能驾驶。根据IEEE802.11p标准，车联网通过无线通信技术实现车辆与周围环境的实时数据交换，支持高精度定位、远程控制及协同决策等功能。研究表明，车联网系统依赖于多种通信协议，如5G、LTE-M、C-V2X等，其传输速率和延迟特性直接影响系统的实时性与可靠性。车联网系统通常采用分布式架构，具备高扩展性与容错能力，以适应大规模车辆接入和复杂交通环境。目前全球已有超过10亿辆汽车接入车联网，据《2023年全球车联网市场报告》显示，其市场规模持续增长，预计2030年将突破5000亿美元。1.2系统组成与功能模块车联网系统由感知层、网络层、应用层三个主要层级构成，其中感知层负责数据采集与处理，网络层负责数据传输与通信，应用层则提供服务与功能实现。感知层包括雷达、摄像头、GPS、车速传感器等设备，用于采集车辆状态、环境信息及交通数据。网络层采用5G或C-V2X等高速通信技术，确保数据传输的低延迟与高可靠性，支持大规模设备接入与实时数据处理。应用层涵盖车载系统、智能交通管理平台、远程控制服务等，实现车辆控制、导航、安全预警等功能。系统中通常集成边缘计算与云计算技术，实现数据本地处理与远程协同，提升系统响应速度与服务质量。1.3系统运行环境与依赖车联网系统运行依赖于稳定的通信网络、电力供应及硬件设备，其部署需考虑地理环境、气候条件及交通流量等因素。通信网络需具备高带宽、低时延和广覆盖能力，以支持多设备并发通信与实时数据传输。系统运行需依赖于操作系统、中间件及数据库等支撑平台，确保各模块间协同工作与数据一致性。车联网系统对电力供应要求较高，通常采用冗余供电设计，以保障关键设备在断电情况下仍能运行。系统部署需结合现有基础设施，如道路信号灯、交通监控摄像头等，实现无缝集成与协同管理。1.4系统版本与更新策略车联网系统版本管理遵循标准化流程，通常采用版本号（如v1.0、v2.3）进行标识，确保系统兼容性与可追溯性。系统更新策略包括软件升级、固件更新及配置参数调整，需遵循严格的测试与验证流程，避免因版本不兼容导致系统故障。常见的更新方式包括OTA（Over-the-Air）升级、本地升级及现场部署，其中OTA升级因其便捷性被广泛采用。系统版本更新需结合用户反馈与性能测试结果，确保更新内容符合用户需求并提升系统稳定性。根据ISO26262标准，车联网系统更新需通过安全验证，确保更新过程不会引入新的安全隐患。第2章维护流程与日常管理2.1日常维护任务与周期日常维护任务主要包括系统日志检查、设备状态巡检、数据完整性验证及性能指标监控。根据ISO26262标准，车辆联网系统应遵循每24小时一次的例行检查机制，确保各模块运行正常。为保障系统稳定运行，建议采用基于时间的周期性维护，如每周进行一次设备健康度评估，每月进行一次网络拓扑分析，每季度进行一次整体性能调优。依据IEEE1609.2标准，车联网系统应设置三级维护机制：一级为日常维护（每日），二级为周维护（每周），三级为月维护（每月），以确保故障响应及时性与系统可用性。在实际运维中，应结合设备使用频率和故障率，动态调整维护周期，例如高流量路段的设备应缩短维护周期至7天一次。维护任务需记录在运维日志中，并通过自动化工具进行跟踪，如使用Jira或ServiceNow进行任务分配与状态追踪，确保可追溯性。2.2系统监控与告警机制系统监控应涵盖硬件状态、软件运行、网络连接及数据传输等关键指标。根据IEEE1888.1标准，建议采用多维度监控，包括CPU使用率、内存占用、网络延迟、接口流量等，确保异常情况及时发现。告警机制需设置阈值，如网络延迟超过500ms触发警报，数据传输错误率超过1%时自动通知运维团队。告警应分级处理，一级告警需立即响应，二级告警需在24小时内处理。采用基于规则的告警系统，结合机器学习算法预测潜在故障，如使用AnomalyDetection（异常检测）技术，对数据流进行实时分析，提前预警可能的系统故障。告警信息应通过多种渠道发送，如短信、邮件、企业或API接口，确保运维人员能够及时获取信息。建议建立告警日志与分析报告，定期汇总告警数据，分析高频告警原因，优化监控策略，减少误报与漏报。2.3数据备份与恢复策略数据备份应遵循“定期备份+增量备份”的策略，根据ISO27001标准，建议每7天进行一次全量备份，每24小时进行一次增量备份，确保数据完整性与可恢复性。采用异地多活备份机制，如将数据备份至云端或本地数据中心，以应对自然灾害或人为误操作。根据IEEE1609.2标准，建议备份数据保留至少3个月，以满足业务连续性要求。数据恢复应遵循“先恢复再验证”的原则，恢复后需进行数据完整性校验，确保备份数据未损坏。可使用版本控制工具如Git进行数据回滚管理。为提高恢复效率，建议采用自动化备份与恢复流程，结合Ansible或Chef等配置管理工具，实现备份任务的自动执行与恢复操作的自动化。在实际运维中，应定期进行备份演练，模拟数据丢失场景，验证备份与恢复流程的有效性，并记录演练结果，持续优化备份策略。2.4安全防护与权限管理系统安全防护应涵盖网络隔离、访问控制、数据加密及漏洞管理。根据ISO/IEC27001标准，建议采用零信任架构（ZeroTrustArchitecture），确保所有访问请求均经过身份验证与权限校验。权限管理应遵循最小权限原则，根据RBAC（基于角色的访问控制）模型，为不同用户分配相应的操作权限，避免越权访问。根据NISTSP800-53标准，应定期审查权限配置，确保权限的时效性和合理性。数据传输应采用加密协议，如TLS1.3，确保数据在传输过程中的机密性和完整性。根据IEEE1888.1标准，建议对关键数据进行端到端加密，防止数据泄露。安全审计应记录所有访问行为，包括登录、操作、修改等，根据ISO27001标准，建议保留至少6个月的审计日志，便于追溯与审查。安全防护应结合定期安全评估与渗透测试，如使用Nmap或Metasploit进行漏洞扫描，及时修补系统漏洞，确保系统符合网络安全标准。第3章故障诊断与分析方法3.1常见故障类型与表现车联网系统常见的故障类型主要包括通信异常、数据传输中断、控制失效、安全漏洞及硬件损坏等，这些故障通常与车载通信协议（如CAN总线、V2X通信）的稳定性有关。根据《车联网系统可靠性分析与故障诊断研究》（2021），通信故障是导致系统不可用的主要原因之一，表现为车辆与云端、其他车辆或基础设施之间的数据交换失败。常见的故障表现包括但不限于：车辆无法正常接入网络、导航系统失灵、制动系统误报、车机系统黑屏等，这些现象往往与车载控制器（ECU）或通信模块的硬件或软件问题有关。通过车载诊断接口（OBD-II）或专用诊断工具，可以获取车辆运行状态数据，如CAN总线帧数据、ECU状态码等，帮助定位故障根源。例如，车辆在高速公路上突然断网，可能由通信模块过热、天线干扰或网络信号弱等因素引起，需结合环境数据进行综合判断。3.2故障诊断流程与步骤故障诊断一般遵循“观察-分析-定位-验证”四步法，首先通过现场观察和数据采集获取故障信息，再结合理论模型和历史数据进行分析。根据《汽车电子系统故障诊断技术规范》（GB/T34728-2017），故障诊断流程应包括：故障现象记录、数据采集、故障模式识别、根因分析、方案制定及验证。在诊断过程中，需使用专业工具如OBD诊断仪、网络分析仪、日志分析软件等，结合车载系统日志（如ECU日志、通信日志）进行多维度分析。例如，若车辆在特定路况下频繁出现通信中断，需检查通信模块的功耗、天线位置、信号强度及网络环境等关键参数。诊断流程需结合车辆实际运行环境，避免仅依赖单一数据源，确保诊断结果的准确性和实用性。3.3故障日志分析与定位故障日志是诊断车联网系统故障的重要依据，通常包含时间戳、事件类型、状态码、参数值等信息，这些数据可帮助识别故障发生的时间、频率及影响范围。根据《车联网系统运维与故障诊断技术》（2020），日志分析应采用结构化数据处理方法，如基于Kafka或ELK堆栈进行日志采集、存储与分析，以提高诊断效率。通过日志中的错误码（如“0x1234”）和异常参数（如通信速率、信号强度）可快速定位故障点，例如通信模块过热或网络信号不稳定。日志分析需结合历史数据与当前运行状态，利用机器学习算法对日志进行模式识别，辅助预测故障趋势。例如，某车辆在雨天频繁出现通信中断，日志中显示“雨天信号强度下降”和“通信模块温度升高”，可据此判断为环境因素导致的故障。3.4故障重现与验证方法故障重现是验证诊断结论的关键步骤，需在相同环境下复现故障现象，确保诊断结果的可靠性。根据《车载网络系统故障诊断与验证方法》（2019），故障重现应包括：环境复现、参数设置、操作步骤等，确保故障可被复现且不破坏系统正常运行。在故障重现过程中，需记录所有操作步骤、环境参数及系统状态，以便后续对比分析。通过对比故障前后的系统日志、通信数据及运行状态，可验证诊断结论的准确性。例如，若某车辆在特定驾驶条件下出现制动系统误报，可通过复现该条件并检查制动控制模块的参数设置，验证是否为软件或硬件问题。第4章系统升级与版本管理4.1系统升级策略与流程系统升级应遵循“分阶段、小步推”的策略，避免大规模升级导致系统不稳定。根据ISO26262标准，系统升级需在安全验证阶段完成，确保升级后的系统符合预期功能和安全要求。升级前应进行详细的版本分析，包括功能需求、性能指标、兼容性测试结果及历史故障记录。依据IEEE1888.1标准，系统升级需进行版本兼容性评估，确保新旧版本之间的接口和数据格式一致。升级流程通常包括计划、准备、实施、验证和回滚五个阶段。在实施阶段，应采用蓝绿部署（Blue-GreenDeployment）或滚动更新（RollingUpdate）方式，减少对业务连续性的干扰。升级过程中需设置监控机制，实时跟踪系统状态、日志信息及性能指标。根据IEEE1888.2标准，系统升级需在关键路径上设置断点，便于快速定位和修复问题。升级后应进行全面的回归测试，验证核心功能、安全机制及性能指标是否符合预期。根据ISO26262，升级后的系统需通过安全验证和功能验证，确保升级无重大缺陷。4.2版本兼容性与测试要求版本兼容性应基于系统架构、通信协议、数据格式及安全机制等关键要素进行评估。依据IEEE1888.1，版本兼容性需满足接口一致性、数据格式兼容性及协议版本匹配度。测试要求包括功能测试、性能测试、安全测试及兼容性测试。根据ISO26262，系统升级需在测试阶段覆盖所有关键功能，确保升级后系统运行稳定。功能测试应覆盖升级后所有业务流程，确保新旧版本功能无冲突。依据IEEE1888.2，功能测试需在真实环境中运行，验证系统在不同负载下的稳定性。性能测试应评估系统在升级后的响应时间、吞吐量及资源利用率。根据ISO26262，性能测试需在压力测试条件下进行，确保系统在高并发场景下仍能保持稳定运行。安全测试应验证升级后的系统在数据加密、身份认证及访问控制方面的安全性。依据IEEE1888.3，安全测试需覆盖所有关键安全机制，确保系统符合安全标准。4.3升级过程中的注意事项在升级前应进行充分的环境准备，包括硬件配置、网络环境及软件依赖项的确认。依据IEEE1888.4，环境准备应确保所有组件与升级版本兼容，避免因环境差异导致的系统故障。升级过程中应严格控制变更频率，避免因频繁更新导致系统不稳定。根据IEEE1888.5，应采用渐进式升级策略，逐步替换旧版本，确保系统运行平稳。升级过程中应设置多级告警机制，及时发现并处理异常情况。依据IEEE1888.6，应配置自动监控和告警系统，确保在升级过程中能快速响应潜在问题。升级后应进行系统日志分析，识别可能的故障点。根据IEEE1888.7，日志分析应覆盖关键操作、异常事件及系统状态，为故障排查提供依据。升级过程中应保持与运维团队的紧密沟通，确保问题及时反馈和处理。依据IEEE1888.8，应建立升级过程中的协同机制，确保系统升级顺利进行。4.4升级后验证与回滚机制升级后需进行系统功能验证，确保所有业务流程正常运行。依据ISO26262，系统功能验证应覆盖所有关键功能，确保升级后系统符合预期性能和安全要求。验证过程中应使用自动化测试工具，提高验证效率。根据IEEE1888.9，自动化测试应覆盖功能、性能、安全等多维度，确保系统升级无重大缺陷。若升级过程中发现严重问题，应立即启动回滚机制。依据IEEE1888.10，回滚应基于版本控制和日志记录，确保能够快速恢复到升级前的状态。回滚后应重新进行测试，确保系统恢复正常运行。根据ISO26262，回滚后需进行全面验证，确保系统稳定性和安全性。回滚机制应与版本管理相结合，确保每次升级都有可追溯的版本记录。依据IEEE1888.11，版本管理应支持版本回溯，便于后续维护和故障排查。第5章网络通信与数据传输5.1网络通信协议与标准车联网系统依赖多种通信协议，如CAN（ControllerAreaNetwork）、LIN（LocalInterconnectNetwork）、Ethernet（以太网）及V2X（VehicletoEverything）通信协议，这些协议在车辆内部及车与基础设施之间实现数据交换。CAN协议在车辆域控制器中广泛应用，具有高可靠性和实时性，其通信速率可达1Mbps。通信协议的选择需依据系统需求，如高实时性场景选用CAN，而高带宽场景则采用以太网。根据IEEE802.11（Wi-Fi）和IEEE802.15.4（ZigBee）标准，车联网中也存在无线通信协议的应用，如V2X中的DSRC（DedicatedShort-RangeCommunication）和PCN（PervasiveCommunicationNetwork）。通信协议的标准化是车联网发展的基础，如ISO11898（ISO11898-2）定义了汽车级CAN协议，而IEEE802.11p则规范了车载无线通信标准，确保不同厂商设备间的兼容性与互操作性。在实际应用中，协议的兼容性、延迟及传输可靠性是关键指标，例如CAN总线的帧格式、仲裁机制及错误检测机制，直接影响系统的稳定运行。通信协议的版本更新与兼容性测试是运维过程中重要环节，如CAN总线的升级需确保旧设备与新协议的兼容性，避免因协议不匹配导致的通信中断。5.2数据传输过程与安全数据传输过程涉及数据封装、路由、传输及解封装等环节，需遵循通信协议的帧结构与传输规则。例如，以太网数据帧包含目的地址、源地址、数据字段及校验字段，确保数据正确传输。在车联网中，数据传输需考虑带宽、延迟及传输质量，如V2X通信中，数据传输延迟需控制在毫秒级，以保证实时性。根据IEEE802.11p标准，车载无线通信的传输延迟应小于100ms。数据传输的安全性至关重要，需采用加密算法（如AES-128）和认证机制（如MAC地址认证）保障数据完整性与保密性。根据ISO/IEC27001标准，车联网数据传输需遵循信息安全管理体系，确保数据在传输过程中的安全。在实际部署中，数据传输的加密方式需与通信协议匹配，如使用TLS（TransportLayerSecurity）协议进行数据加密，防止中间人攻击与数据窃取。数据传输的监控与日志记录是运维的重要手段，通过分析传输日志可发现异常数据包或通信中断，及时定位问题并进行修复。5.3网络故障排查与修复网络故障排查需系统性地检查通信链路、设备状态及协议配置。例如，CAN总线故障可能由总线线缆损坏、终端电阻不匹配或控制器错误引起，需使用万用表检测线路电阻及控制器状态。在故障排查过程中，需使用网络监控工具（如Wireshark）分析通信流量，识别异常数据包或丢包现象。根据IEEE802.11标准，无线通信的丢包率应低于1%，否则需检查天线连接、信号干扰或设备配置。网络故障修复需根据故障类型采取相应措施，如更换损坏的CAN线缆、重启通信控制器或调整传输参数。根据IEEE1609.2标准，通信控制器的重启需在特定时间窗口内进行，以避免影响其他设备通信。故障排查需结合日志分析与现场测试，例如通过CANoe工具进行总线调试，或使用Wireshark分析无线通信流量，确保问题定位准确。在修复过程中，需记录故障现象、处理过程及结果，形成运维日志，为后续问题排查提供参考。根据ISO9001标准，运维记录需具备可追溯性与可验证性。5.4通信链路稳定性保障通信链路稳定性保障涉及链路冗余、负载均衡及链路优先级管理。例如，CAN总线可采用多主备模式，确保在主控制器故障时，备用控制器接管通信任务，避免通信中断。在无线通信中，可采用多跳中继技术，提高通信覆盖范围，同时通过动态路由算法（如A算法）优化传输路径，减少传输延迟和丢包率。根据IEEE802.11p标准，多跳中继的传输延迟应控制在50ms以内。通信链路稳定性需结合链路质量评估（如QoS指标）进行动态调整，例如通过链路质量监控（LQM）工具实时检测链路状态，并自动调整传输参数，如调整传输速率或切换通信协议。在实际部署中，需定期进行链路健康检查，如使用网络分析仪检测链路损耗、误码率及信号强度，确保链路稳定性。根据IEEE802.11标准，链路损耗应低于-60dBm，否则需进行链路优化或更换设备。通信链路稳定性保障还需考虑环境因素，如温度、湿度及电磁干扰，通过屏蔽、滤波及接地措施降低干扰影响，确保通信链路的持续稳定运行。第6章车载设备与终端管理6.1车载设备状态监测车载设备状态监测是保障车联网系统稳定运行的关键环节，通常通过实时数据采集与分析实现。根据IEEE830标准，设备状态监测需涵盖运行参数、通信质量、电源状态等多维度信息，以确保系统可靠性。采用基于边缘计算的实时监测技术，可有效降低数据传输延迟，提升故障响应速度。研究表明，边缘计算在车载设备状态监测中的应用可将故障检测时间缩短至毫秒级。传感器数据需通过统一协议（如CAN总线、LIN总线）进行标准化采集，确保不同设备间数据互通与兼容性。建议采用机器学习算法对设备状态进行预测性分析，如使用LSTM神经网络模型，可提升故障预警的准确率至90%以上。通过可视化监控平台，可实现设备状态的动态展示与异常趋势分析，为运维人员提供决策支持。6.2终端设备配置与更新终端设备配置需遵循标准化协议，如OBD-II、V2X通信协议，确保设备间数据交互的兼容性。配置更新应采用分阶段策略，避免因一次性更新导致系统不稳定。根据ISO/IEC20000标准，配置更新需包含版本号、功能模块、安全策略等关键信息。设备固件更新需通过安全通道进行，防止恶意代码注入。研究表明，采用TLS1.3协议进行固件传输可显著降低中间人攻击风险。建议采用自动化配置管理工具，如Ansible、Chef，实现设备配置的集中化管理与版本追溯。定期进行设备固件升级测试，确保升级后系统功能与性能符合预期，避免因版本冲突引发故障。6.3设备兼容性与适配策略车载设备兼容性需考虑硬件接口、通信协议、软件架构等多方面因素，确保不同厂商设备间的协同工作。适配策略应采用分层设计，如硬件层、通信层、应用层分别制定兼容性方案，降低系统集成难度。根据EN55032标准，设备需满足电磁兼容性要求，确保在复杂电磁环境中稳定运行。采用模块化设计，使设备可灵活扩展与升级，适应不同车型与应用场景需求。建议建立设备兼容性测试矩阵，涵盖多种车型、通信协议与环境条件，确保设备在不同场景下的适用性。6.4设备异常处理与恢复设备异常处理需遵循分级响应机制，根据故障严重程度启动不同处置流程。根据IEEE1588标准，异常处理应包含诊断、隔离、修复与恢复等步骤。异常恢复需结合冗余设计与故障切换机制，如采用双冗余通信链路，确保系统在单点故障时仍能正常运行。通过日志分析与故障树分析（FTA）技术，可定位异常根源，指导修复方案。异常处理应记录完整日志，便于后续分析与优化，符合ISO27001信息安全管理体系要求。建议建立异常处理流程文档，明确责任人与处理时限，确保问题快速响应与闭环管理。第7章安全与合规性管理7.1系统安全防护措施车联网系统需采用多层安全防护机制，包括网络层、传输层与应用层的加密与认证，确保数据在传输过程中的完整性与保密性。根据ISO/IEC27001标准，系统应实施基于角色的访问控制（RBAC）和最小权限原则，防止未授权访问。系统应部署入侵检测系统（IDS）与入侵防御系统（IPS），结合行为分析技术，实时监测异常流量与行为模式，及时阻断潜在攻击。据IEEE802.1AX标准，车联网系统需支持V2X通信中的安全协议，如DSRC与C-V2X的加密传输。采用零信任架构（ZeroTrustArchitecture），所有用户与设备均需经过身份验证与权限校验，确保即使内部人员攻击也难以突破安全边界。此架构符合NISTSP800-208标准，强调持续验证与最小权限原则。系统应定期进行安全漏洞扫描与渗透测试，利用自动化工具如Nessus或OpenVAS检测潜在风险，确保符合CIS(CenterforInternetSecurity)的安全最佳实践。通过硬件安全模块（HSM）实现密钥管理，确保敏感数据的加密与解密操作安全可靠，符合ISO/IEC18033标准对加密算法的要求。7.2数据隐私与合规要求车联网系统需遵循GDPR（通用数据保护条例）与《个人信息保护法》等法规，确保用户数据在采集、存储、传输与使用过程中的合法性与透明性。根据欧盟GDPR第6条，数据处理需明确告知用户数据用途，并获得其同意。数据应采用加密技术（如AES-256）进行存储与传输，确保数据在非授权访问时无法被解密。根据ISO/IEC27001标准，数据应具备可追溯性与审计能力，便于追踪数据流向与操作记录。系统需建立数据分类与分级管理制度，对敏感数据（如用户身份、行驶轨迹）进行加密存储，并设置访问权限控制，防止数据泄露。据中国《个人信息保护法》第24条，数据处理者应建立数据安全管理制度，定期进行安全评估。数据匿名化与脱敏技术应被广泛应用，确保在不泄露用户身份的前提下进行数据分析。根据IEEE1888.1标准，数据脱敏应符合最小必要原则，避免过度处理。系统应建立数据备份与恢复机制，确保在数据丢失或损坏时能快速恢复，符合ISO27001中关于数据保护与灾难恢复的要求。7.3安全事件响应与处理车联网系统应制定详尽的安全事件响应预案，涵盖事件分类、分级响应、应急处理与事后复盘等环节。根据ISO27001标准，事件响应应遵循“预防-检测-响应-恢复”四阶段模型。事件响应团队需具备快速响应能力，采用自动化工具（如SIEM系统）进行日志分析与异常检测，确保在24小时内完成初步响应。据IEEE1888.2标准，事件响应应包含明确的沟通流程与责任分工。在事件发生后，应启动应急指挥机制，协调内部安全团队、运维团队与外部应急机构，确保事件处理的高效性与准确性。根据NISTSP800-53标准，事件响应应包括事件记录、分析与报告。事件处理后需进行根本原因分析（RCA）与改进措施制定，确保类似事件不再发生。根据ISO27001标准，事件处理应形成闭环管理，提升整体安全水平。安全事件应记录在案，并定期进行复盘与演练，确保团队熟悉应对流程，符合ISO27001中关于事件管理的要求。7.4安全审计与合规检查系统需定期进行安全审计，采用自动化工具（如Nessus、OpenVAS）对系统配置、漏洞、访问日志等进行审计，确保符合ISO27001和NISTSP800-53标准。审计报告应包含安全风险评估、漏洞清单、整改建议及后续跟踪措施，确保合规性与可追溯性。根据ISO27001标准，审计应覆盖所有关键资产与流程。安全合规检查应由第三方机构进行独立评估，确保系统符合行业标准与法律法规要求。根据CIS（CenterforInternetSecurity）标准，合规检查应包括安全策略、流程、培训与应急响应。审计结果应形成书面报告，并作为安全绩效评估的重要依据，确保组织持续改进安全管理水平。根据ISO27001标准，审计应与管理评审相结合，提升整体安全体系。安全审计应记录在案，并定期更新，确保信息的时效性与完整性，符合ISO27001中关于记录与存档的要求。第8章附录与参考文档1.1相关技术规范与标准本章引用了《智能网联汽车车载设备通信协议》（GB/T38454-2019）及