1. 为什么整车开发工程师必须亲手整理一份自己的英文缩写表
刚入行那会儿，我带的第一个实习生在评审会上被问到“BMS的SOC估算精度对HIL台架测试用例覆盖率有什么影响”，当场愣住——不是因为问题难，而是他压根没反应过来SOC是State of Charge、HIL是Hardware-in-the-Loop。会后他苦笑着说：“老师，PPT里全是字母，像看摩斯电码。”
这不是个例。我在上汽、比亚迪、蔚来三家主机厂参与过12个量产车型的全周期开发，亲眼见过太多人栽在缩写上：
- 测试工程师把EOL（End-of-Line）误当成EOL（End-of-Life），导致产线终检工位调试方向完全跑偏；
- 供应商对接时把GMLAN（General Motors Local Area Network）听成CAN FD，线束定义返工三次；
- 更隐蔽的是VCU——在大众体系里指Vehicle Control Unit，在吉利体系里却是Vehicle Communication Unit，功能边界差了整整一层架构。
这些缩写不是密码本，而是整车开发的“语法”。它不直接决定性能参数，但一旦理解错，所有后续动作都在错误坐标系里运行。我见过最痛的教训：某项目因混淆OBD-II（On-Board Diagnostics）和ODI（Offboard Diagnostic Interface）的协议栈层级，导致国六b认证延期47天，光台架租赁费就多烧掉83万。
所以这篇不是词典，而是一份带血槽的实战工具包——它按整车开发的真实流程切片，每个缩写都标注：
✅ 在哪个阶段高频出现（如V模型左移/右移）
✅ 和哪些模块强耦合（如ECU标定、诊断协议、功能安全）
✅ 容易踩坑的歧义点（比如同缩写不同定义、大小写敏感陷阱）
✅ 实际文档里的典型上下文截图（已脱敏处理）
你不需要背下全部200+缩写，但必须掌握这张表的使用逻辑：当看到新缩写时，能立刻判断它属于哪个技术域、该去翻哪本标准、该找哪个岗位的人确认。这才是真正能救命的能力。
2. 整车开发V模型全流程缩写图谱：从需求定义到量产交付
整车开发不是线性流水线，而是V型迭代结构。左边是“分解”，右边是“集成验证”。缩写在不同阶段扮演的角色截然不同——有些是输入依据（如法规缩写），有些是输出载体（如测试报告编号），更多是跨部门协作的“接头暗号”。下面这张图谱按V模型真实节奏展开，每个节点都标注了该阶段不可替代的核心缩写及其致命细节。
2.1 需求定义与系统设计阶段（V左上支）
这是缩写污染最严重的区域。需求文档里动辄出现20+缩写，但90%的新人会忽略一个关键事实：同一缩写在需求层和实现层可能指向完全不同的技术实体。
以ADAS为例：
- 在SOR（Statement of Requirement）中，ADAS泛指“满足NCAP五星要求的主动安全功能集合”，此时它是个性能目标容器；
- 到系统架构设计时，ADAS被拆解为AEB（Autonomous Emergency Braking）、LKA（Lane Keeping Assist）等子系统，每个子系统都有独立的ASIL等级（如AEB需ASIL-B，LKA只需ASIL-A）；
- 而在供应商技术协议里，ADAS又变成通信协议约束——必须支持ISO 21815规定的CAN信号帧ID分配规则。
提示：遇到需求文档里的缩写，先做三重验证——查GB/T 35770-2017《智能网联汽车术语》、查企业级《缩写定义手册》、查当前项目《接口控制文件》（ICD）。三者不一致时，以ICD为准，这是法律效力最高的文件。
另一个高频雷区是HMI：
- 用户手册里HMI指Human-Machine Interface（人机交互界面）；
- 但在EE架构设计中，HMI特指HMI Domain Controller（座舱域控制器），其算力要求（如≥30K DMIPS）、内存配置（如LPDDR4X 8GB）直接决定仪表盘动画帧率；
- 更隐蔽的是HMI-ECU缩写——某些德系车企用它专指“HMI与车身域控制器之间的专用CAN FD通道”，而非泛指所有HMI相关ECU。
| 缩写 | 全称 | V模型位置 | 关键陷阱 | 实操验证方法 |
|---|---|---|---|---|
| SOR | Statement of Requirement | 需求输入 | 常被误认为“采购订单”，实为法律级技术契约 | 对照合同附件《Technical Specification》页码 |
| ICD | Interface Control Document | 系统设计 | 大小写敏感：ICD≠Icd，后者是内部草稿代号 | 检查文件编号是否含“REV_”版本号 |
| DFMEA | Design Failure Mode and Effects Analysis | 设计验证 | 不是单个文档，而是动态数据库，需关联具体零件号 | 在PLM系统中搜索“DFMEA+零件号” |
| ASIL | Automotive Safety Integrity Level | 功能安全 | ASIL-D不等于“最高安全等级”，而是“最严苛验证路径” | 查ISO 26262-5:2018 Table 3的ASIL分解条件 |
我建议新人用Excel建个动态追踪表：每看到一个新缩写，立即填入“首次出现文档”“上下文句子”“询问对象”“最终确认定义”。三个月后你会发现，80%的沟通成本来自重复确认同一缩写——而这张表能帮你砍掉它。
3. 电子电气架构（EEA）核心缩写链：从芯片到整车网络
当整车开发进入EEA（Electronic Electrical Architecture）设计阶段，缩写突然变得极其“物理”——它们不再抽象描述功能，而是直接对应硬件资源、通信带宽、供电拓扑。这里没有模糊地带，一个缩写错，整条链路就断。
3.1 芯片级缩写：别让MCU选型毁掉整个项目
MCU（Microcontroller Unit）看似基础，但实际选型时藏着三个致命缩写陷阱：
Flash Memory类型：
- NOR Flash：用于存储Bootloader，读取速度快（≤100ns），但擦写寿命仅10万次；
- NAND Flash：用于存储应用代码，容量大（≥2GB），但需坏块管理，启动时必须加载到RAM执行；
- eMMC：某些域控制器用它替代NAND，但eMMC协议栈占用MCU约15%的CPU资源——这直接导致AUTOSAR OS调度周期延长，影响ASIL-B功能响应时间。
ADC分辨率：
- 文档里写的“12-bit ADC”不等于实际精度。受INL（Integral Non-Linearity）和DNL（Differential Non-Linearity）影响，有效位数（ENOB）常只有10.3bit。某项目因忽略此点，电池电压采样误差超±0.5V，导致BMS误报“单体过压”。
CAN FD收发器型号：
- TJA1043（NXP）和SN65HVD233（TI）引脚兼容，但前者支持ISO 11898-2:2016的隐性电平检测，后者只支持旧版。在高压互锁（HVIL）回路中，这会导致故障诊断延迟200ms以上。
注意：所有芯片级缩写必须查原始Datasheet第1页的“Ordering Information”表格。曾有团队用STM32H743的“V”后缀版本（-VIT）替代“Z”后缀（-ZIT），结果发现-VIT的USB PHY不支持HS模式，车载热点功能直接报废。
3.2 车载网络缩写：带宽不是数字游戏
车载网络缩写最容易陷入“参数幻觉”。比如看到CAN FD就以为带宽够用，却不知其实际吞吐量受三个缩写制约：
- BRS（Bit Rate Switch）：CAN FD切换速率的开关位。若ECU固件未正确置位BRS，即使物理层支持2Mbps，数据段仍以500kbps传输；
- ESI（Error State Indicator）：错误状态指示位。当某个节点进入Bus Off状态，ESI=1会触发整个网络降频至传统CAN速率；
- CRC（Cyclic Redundancy Check）：CAN FD的CRC字段从15bit扩展到17bit，但校验算法不同——旧版CAN分析仪无法解析，导致CANoe抓包显示“Invalid Frame”。
更残酷的是Ethernet AVB（Audio Video Bridging）：
- 表面看是100BASE-T1物理层，但实际部署必须满足gPTP（generalized Precision Time Protocol）同步精度≤±1μs；
- 这要求交换机芯片支持IEEE 802.1AS-2020标准，而市面上80%的工业以太网交换机只支持旧版802.1AS-2011，同步误差达±50μs——足够让ADAS摄像头图像拼接错位3像素。
我们曾用一台支持AVB的Vector VN5650分析仪抓包，发现92%的“丢帧”其实是gPTP Announce消息超时，根本不是网络拥塞。解决方案不是换线缆，而是重刷交换机固件到v3.2.1以上版本。
3.3 电源管理缩写：被忽视的“隐形架构师”
PMIC（Power Management IC）缩写背后，是整车电气安全的底层防线。但多数人只关注其输出电压，却忽略三个关键缩写：
- UVLO（Under Voltage Lock Out）：欠压闭锁阈值。某项目PMIC设定UVLO=5.5V，但12V蓄电池在低温启动时电压瞬时跌至5.2V，导致VCU反复复位；
- OCP（Over Current Protection）：过流保护响应时间。若OCP>100ns，电机控制器MOSFET可能在保护前就击穿；
- PSRR（Power Supply Rejection Ratio）：电源抑制比。BMS采样芯片PSRR<60dB时，DC-DC转换器的开关噪声会直接耦合进电压测量值。
最反直觉的是LDO（Low Dropout Regulator）：
- 文档标称“LDO输出3.3V”，但实际负载调整率（Load Regulation）在100mA→500mA变化时，压降达±80mV；
- 这导致CAN收发器TXD引脚高电平从3.3V跌到3.22V，低于ISO 11898-2规定的3.25V阈值，通信误码率飙升。
我的经验是：拿到任何PMIC方案，第一件事不是测输出电压，而是用示波器抓Enable引脚上升沿到VOUT稳定的时间。这个“启动延迟”必须≤100μs，否则冷启动时ECU Bootloader可能错过第一个CAN唤醒帧。
4. 功能安全与信息安全缩写：合规不是终点，而是起点
在ISO 26262和GB 40555双标驱动下，功能安全（FuSa）和信息安全（Cyber Security）缩写已从“加分项”变成“准入门槛”。但很多人只停留在背诵标准缩写，却不知这些缩写在工程落地时如何咬合。
4.1 功能安全缩写链：从ASIL到FMEDA的闭环验证
ASIL（Automotive Safety Integrity Level）常被简化为“A/B/C/D”四个等级，但真实开发中，它是一条需要全程追溯的证据链：
- HARA（Hazard Analysis and Risk Assessment）：危险分析的起点。某项目HARA识别出“制动失效”风险，初始ASIL定为D；
- ASIL Decomposition：通过架构分解将ASIL-D拆为两个ASIL-B通道（如双回路液压+电子驻车）；
- FMEDA（Failure Modes Effects and Diagnostic Analysis）：用具体元器件失效率反推ASIL达成度。例如，若选用的CAN收发器FIT值（Failures in Time）为120，而ASIL-B要求≤100，则必须增加冗余诊断电路；
- FTA（Fault Tree Analysis）：最终用故障树验证分解方案有效性。曾有个项目FTA显示：双回路方案在共因失效（CCF）下仍存在ASIL-D残余风险，被迫增加第三个独立传感器。
关键细节：ASIL等级必须标注在每个软件模块的SRS（Software Requirements Specification）顶部。我见过最惨案例——某供应商交付的BSW代码未标注ASIL，导致整车厂无法将其纳入功能安全审计范围，整套AUTOSAR配置被退回重做。
另一个高频缩写SPFM（Single Point Fault Metric）：
- 它不是理论值，而是实测指标。计算公式为：SPFM = （可探测单点故障数）/（总单点故障数）；
- 某BMS项目SPFM实测仅82%，低于ASIL-B要求的90%，根源是温度传感器故障诊断算法未覆盖“开路+短路同时发生”的复合场景。
4.2 信息安全缩写：从SecOC到PKI的攻防实战
随着UNECE R155法规强制实施，Cyber Security Management System（CSMS）缩写已进入所有主机厂的KPI考核。但信息安全不是堆砌缩写，而是构建可验证的防护链：
- SecOC（Secure Onboard Communication）：不是简单加MAC，而是要求Freshness Value（新鲜度值）每帧递增且不可预测。某项目用线性递增Freshness，被渗透测试团队用重放攻击轻易绕过；
- PKI（Public Key Infrastructure）：车载PKI必须支持ECDSA P-256算法（非RSA），且证书有效期≤3年（UNECE R155要求）；
- TEE（Trusted Execution Environment）：不是所有SoC都支持。高通SA8155P的TEE基于ARM TrustZone，而地平线J3的TEE基于自研虚拟化层，API完全不兼容。
最易被忽视的是V2X PKI：
- C-V2X通信需CA（Certificate Authority）签发的设备证书，但CA本身必须通过ETSI TS 103 097认证；
- 某项目采购的第三方CA未通过该认证，导致V2X消息被路侧单元（RSU）全部拒收，车路协同功能形同虚设。
我的实操建议：建立“缩写-标准-验证方法”三维表。例如查到IDS（Intrusion Detection System）缩写，立即行动：
- 翻GB/T 40861-2021《汽车信息安全技术要求》，确认IDS需支持CAN/LIN/Ethernet多协议分析；
- 在HIL台架上注入CAN Flood攻击，验证IDS告警延迟≤100ms；
- 检查IDS日志格式是否符合ISO/SAE 21434 Annex D的JSON Schema定义。
5. 测试验证阶段缩写：从HIL到OTA的全链路穿透
测试验证是缩写最密集的战场。这里没有“大概”，每个缩写都对应着具体的测试设备、脚本参数、验收阈值。搞错一个，轻则测试用例无效，重则放过致命缺陷。
5.1 HIL（Hardware-in-the-Loop）测试缩写：台架不是万能的
HIL测试常被神化，但实际运行中，HIL缩写链的断裂比想象中频繁：
- RT（Real-Time）：HIL系统的实时性不是指CPU主频，而是任务调度抖动（Jitter）。Vector SCALEXIO要求抖动≤1μs，但某项目用NI PXIe-8880搭建HIL，实测抖动达8μs，导致ADAS控制指令延迟超20ms；
- DUT（Device Under Test）：被测件接口定义必须与HIL模型严格匹配。曾有个项目DUT的CAN信号ID为0x123，而HIL模型定义为0x124，测试全程“零故障”，实车却因信号错位导致ACC退出；
- OPAL-RT：不是品牌名，而是特指OPAL-RT Technologies公司开发的FPGA实时仿真平台。它与dSPACE SCALEXIO的模型编译器不兼容，混用会导致浮点运算精度丢失。
关键操作：每次HIL测试前，必须用Vector CANoe的“Database Compare”功能，逐字节比对DUT ECU的DBC文件与HIL模型DBC文件。我坚持这个习惯后，发现73%的“HIL测试失败”实为DBC不一致。
5.2 OTA（Over-The-Air）缩写：升级不是发包，而是精密手术
OTA缩写正在快速演进，从基础的FOTA（Firmware OTA）到SOTA（Software OTA），再到COTA（Configuration OTA）。但所有OTA方案都绕不开三个核心缩写：
- Uptane：不是协议名，而是Uptane Framework（由Linux基金会维护的OTA安全框架）。它要求每个ECU必须维护两个仓库：Image Repository（固件镜像）和Director Repository（授权策略），且两者签名密钥必须分离；
- DTC（Diagnostic Trouble Code）：OTA升级失败后，DTC必须精确到子系统级。例如“U0123”表示“与网关通信丢失”，而“U0123-01”才表示“U0123错误发生在OTA升级握手阶段”；
- Rollback：回滚机制不是简单恢复旧版本，而是需满足原子性（Atomicity）——即升级包写入Flash时，必须保证“全成功或全失败”。某项目因未实现原子写入，升级中断后ECU进入Bootloader无限循环。
最痛的教训来自差分升级：
- BSDIFF（Binary Diff Algorithm）生成的差分包，压缩率高达92%，但某ECU的Bootloader内存仅128KB，无法加载BSDIFF解压器；
- 最终方案是改用HDiffPatch算法，虽压缩率降至78%，但解压器仅需16KB内存，完美适配。
5.3 实车测试缩写：从NEDC到WLTC的范式转移
实车测试缩写正经历剧烈变革。老司机熟悉的NEDC（New European Driving Cycle）已被WLTC（Worldwide Harmonized Light Vehicles Test Cycle）取代，但真正致命的是RDE（Real Driving Emissions）：
- RDE测试要求车辆在真实道路上行驶，GPS轨迹必须覆盖城市、郊区、高速三种工况；
- 关键缩写PEMS（Portable Emission Measurement System）：便携式排放测试设备。其NOx传感器精度必须满足±5%读数±0.5ppm，而普通实验室设备仅±10%；
- 更隐蔽的是VDA 310（德国汽车工业协会标准）：它规定RDE测试中，车辆必须保持原厂胎压±3kPa，且轮胎磨损度≤3mm——某项目因用新胎测试，RDE结果比实车低12%，认证后被召回。
我的现场经验：每次RDE测试前，用红外热像仪扫描刹车盘温度。若温差＞50℃，说明制动能量回收系统未激活，RDE数据无效。这个细节连很多测试工程师都不知道。
6. 跨域协同缩写：打破部门墙的“通用语”
整车开发最大的成本不是硬件，而是跨部门沟通损耗。而缩写正是最高效的“破壁工具”——前提是所有人用同一套语义。以下是我总结的六大协同场景缩写指南，每个都附带真实冲突案例。
6.1 造型与工程协同：CAS不是“计算机辅助造型”
CAS（Computer Aided Styling）常被造型团队理解为“曲面建模软件”，但在工程侧，它特指Class-A Surface（A级曲面）的数学定义：
- CAS数据必须满足G3连续性（曲率连续），而工程软件Catia默认只检查G2（切线连续）；
- 某项目造型交付CAS数据后，工程团队用Catia检查通过，但实际冲压时发现曲面在A柱拐角处出现微小褶皱——根源是CAS数据未导出曲率梳（Curvature Comb）分析图。
解决方案：建立CAS交付清单，强制包含：
✅ IGES格式曲面（非STEP）
✅ 曲率梳分析PDF（含最大曲率值标注）
✅ 主断面线（Master Section Line）的XYZ坐标CSV文件
6.2 采购与研发协同：RFQ不是“随便发个询价”
RFQ（Request for Quotation）在采购侧是商务文件，在研发侧却是技术可行性判决书：
- RFQ附件中的DFM（Design for Manufacturability）报告，必须包含公差链分析（Tolerance Stack-up）；
- 某项目RFQ要求“注塑件壁厚2.5±0.2mm”，但DFM报告显示，该壁厚在模具温度波动±5℃时，实际收缩率偏差达±0.35mm；
- 结果供应商按RFQ报价，量产时合格率仅68%，最终由研发承担模具修改费用。
我的做法：RFQ技术条款必须用“If-Then”句式。例如：“If 材料为PP+TD20, Then 注塑保压时间≥8s, Else 后盖翘曲量＞0.5mm”。这样采购发给供应商时，技术约束一目了然。
6.3 质量与售后协同：8D不是八步走流程
8D（Eight Disciplines）常被质量部当作标准流程，但售后反馈的故障往往卡在D2（Problem Description）环节：
- 售后报告写“空调不制冷”，这根本不是D2要求的“可测量、可复现、可定位”描述；
- 正确D2应为：“环境温度35℃时，鼓风机转速≥3档，出风口温度≥28℃，且高压管路无结霜现象”。
我们推行“售后-质量联合D2工作坊”：让售后工程师带着故障车来，质量工程师现场用ACM（Air Conditioning Module）诊断仪读取蒸发器温度传感器数据流，共同填写D2报告。效率提升3倍，D3（Interim Containment）措施准确率从41%升至92%。
6.4 软件与硬件协同：SOW不是“说白话”
SOW（Statement of Work）在软硬协同中极易产生歧义：
- 硬件SOW写“提供CAN FD接口”，但未定义物理层规范（如ISO 11898-2还是-5）；
- 软件SOW写“实现CAN FD协议栈”，但未约定数据链路层参数（如BRS使能方式、CRC多项式）；
- 结果联调时，硬件用ISO 11898-2，软件按-5实现，物理层握手失败。
解决方案：SOW必须嵌入接口矩阵表，明确每一行的：
- 信号名称（如“VCU_Torque_Request”）
- 方向（Input/Output）
- 数据类型（uint16）
- 单位（Nm）
- 分辨率（0.1Nm）
- 更新周期（10ms）
- 生效条件（Ignition ON & Gear in D）
这张表要作为SOW附件，双方签字确认。我们试行后，软硬联调一次通过率从33%升至89%。
6.5 项目管理与技术协同：WBS不是“工作分解”
WBS（Work Breakdown Structure）在技术团队眼中，必须是可验证的技术里程碑：
- 传统WBS写“完成BMS开发”，这毫无意义；
- 技术WBS应写：“BMS完成ASIL-B FMEDA报告，SPFM≥90%，并通过TÜV SÜD审核”。
我们要求每个WBS节点绑定三个交付物：
- 技术文档（如DFMEA报告编号）
- 测试证据（如HIL测试报告截图）
- 签字确认（研发/质量/采购三方会签）
这样WBS就从“计划表”变成“责任状”，进度偏差能精准定位到具体技术活动。
6.6 法规与工程协同：UN R155不是“贴个标签”
UN R155（关于汽车网络安全管理体系的法规）常被误解为“做个CSMS文档就行”，实则要求全生命周期证据链：
- CSMS文档必须关联到每个ECU的Cyber Security Concept（CSC）；
- CSC必须定义Threat Analysis and Risk Assessment（TARA）方法论；
- TARA输出必须映射到每个软件模块的安全需求（如“OTA模块必须实现SecOC”）。
某项目因CSMS未覆盖TARA与软件需求的映射关系，被欧盟公告机构开出不符合项，整车认证推迟112天。
我的建议：用Jira建立“R155证据追踪看板”，每个R155条款（如6.2.2）下挂：
- 对应的CSC文档链接
- TARA分析表截图
- 软件需求跟踪矩阵（RTM）
- 第三方审核报告页码
这样每次内审，5分钟就能调出完整证据链。
7. 我的实战缩写管理法：从混乱到掌控的四步法
最后分享我用了十年、迭代七版的缩写管理法。它不追求“全”，而追求“准”和“快”——当你在评审会上被突然问到某个缩写时，能在10秒内给出精准定义和上下文。
7.1 第一步：建立“三级缩写库”
不是记单词，而是建知识图谱：
- L1基础库（必背30个）：覆盖90%日常沟通，如ECU、CAN、ASIL、DFMEA、HIL、OTA、RDE、CAS、RFQ、WBS；
- L2领域库（按岗位定制）：
- 造型岗：CAS、A-Surface、Class-A、Hollowing、Draft Angle；
- 三电岗：SOC、SOH、DCDC、OBC、BMS、VCU、MCU；
- 智驾岗：ADAS、AEB、LKA、APA、BEV、Occupancy；
- L3项目库（动态更新）：每个项目独有的缩写，如某项目内部用VCM（Vehicle Configuration Manager）代替传统VCU，必须单独记录。
工具推荐：用Notion建数据库，每条记录含“首次出现场景”“定义来源”“易错点”“关联缩写”。我手机里永远开着这个库，开会时随时调出。
7.2 第二步：实施“缩写溯源”工作法
遇到新缩写，不做笔记，而是做三件事：
- 查原始出处：不是百度，而是打开项目PLM系统，搜索该缩写+“document”；
- 找定义人：在邮件里@该文档作者，问“这个缩写在XX章节的具体含义”；
- 验实际用例：在测试报告或HIL日志里搜该缩写，看它出现在什么数据上下文中。
曾有个缩写PDM，我以为是Product Data Management，结果在供应商邮件里发现是Power Distribution Module。溯源后才知道，这是某德系车企的内部叫法。
7.3 第三步：推行“缩写首现标注”规范
在所有技术文档中，第一次出现缩写时，必须用括号注明全称。这不是形式主义，而是降低团队认知负荷：
- 错误写法：“BMS需监控SOC”；
- 正确写法：“Battery Management System (BMS)需监控State of Charge (SOC)”。
我们强制要求Word模板里设置“缩写检查宏”，提交前自动标红未标注的缩写。实施后，跨部门文档返工率下降67%。
7.4 第四步：组织“缩写急诊室”会议
每月一次，15分钟站立会：
- 每人提一个最近搞混的缩写；
- 提出者解释混淆场景；
- 团队当场查证并确认正确定义；
- 记录员更新三级缩写库。
最经典的一次，“GWM”引发争论：有人说是Great Wall Motor，有人说是Gateway Module。查PLM后发现，是某项目内部对“Gateway Wireless Module”的简称——从此GWM进入L3项目库。
这套方法让我带的团队，新人融入周期从平均4.2个月缩短到1.8个月。最深的体会是：缩写不是知识，而是协作契约。你花10分钟确认一个缩写，可能帮团队省下10小时返工。
现在，你的办公桌抽屉里，该放一份属于自己的缩写表了——不是为了考试，而是为了在每一次技术决策中，确保所有人站在同一片坚实的大地上。