GB/T.1-英文版翻译道路车辆网联车辆方法论第1部分：通用信息
提供更多标准英文版。
1范围
本文件规定了网联车辆的通用信息。本文件适用于M类、N类车辆。
2规范性引用文件
下列文件中的内容通过文中的规范性引用而构成本文件必不可少的条款。其中，注日期的引用文件，仅该日期对应的版本适用于本文件E不注日期的引用文件，其最新版本（包括所有的修改单）适用于本文件。
GB/T.2道路车辆网联车辆方法论第2部分：设计导则CGB/T.2-,ISO-2:,MOD)
3术语和定义
GB/T.2界定的以及下列术语和定义适用于本文件。
3.1
间联车辆extendedvehicle
满足车辆制造厂的规范要求，但是超出了道路车辆的物理范围，由道路车辆、外部接口、网联附件以及通过外部接口产生的数据通信组成的车辆系统。
注1：网联车辆可以没有网联附件。
注2：当通信对象为非网联附件（例如，道路基础设施、其他交通参与者〉时，网联车辆自道路车辆、外部接口以及通过外部接口产生的数据通信组成，道路基础设施和其他交通参与者不属于网联车辆。
注3：网联车辆的常见应用领域见附录B，网联车辆方法论标准见附录c.
3.2
车外系统off-boardsystem
针对道路车辆，通过定义、设计、开发和／或制造，用于实现所需功能的车外软件与硬件。
3.3
网联附件extendedaccessory
由网联车辆制造厂提供并用于实现网联功能的车外系统。
3.4
车辆制造厂manufacturer
颁发机动车出厂合格证或产品一致性证明并承担车辆产品责任和车辆识别号码（VIN）的唯一性责任，且与装配厂所在位置无关的厂商或公司。
3.5
同联车辆制造厂ExVemanufacturer
生产网联车辆的车辆制造厂。
3.6
功能需求functionalrequirement为保证必要的行为和／或结果，由车辆制造厂给出的描述。
注2功能需求由负责产品或流程设计的机构给出。
3.7
功能function
为满足功能需求而实施的任务、行为或活动。
示例：开启关闭发动机。
注2同一功能可以用于多种不同用例。
3.8
用倒usecase
一个或多个参与者与相关系统的交互序列，该交互序列有特定目标和可量化的结果。
示例：读取所有有效诊断故障码。
注1：“读取所有有效诊断故障码”可以自以下交互组成：通信初始化、车辆识别、发送请求以得到诊断故障码信息、接收诊断故障码信息、通信结束。
注2：操作者可以是人类，也可以是机器。
注3：为了实施网联车辆的设计，需由适当的场景和功能需求来确定用例。
3.9
用例集usecasecluster具有相同目标和可量化的结果的一组用例。示例：远程诊断、车队管理。
注1：用例集本身可以重新划分为不同的领域，在这些领域可能产生不同类型的技术解决方案，有些解决方案适用于多个领域。
注2：网联车辆可用于所有车辆互联的用例集领域，例如，合作式ITS、车队管理、远程诊断、车辆共享等。
3.10
网络服务webservice
用于通过网络进行设备交互并具备机器可处理格式接口的软件系统。
4缩略语
ExVe：网联车辆（ExtendedVehicle)
FMS：车队管理系统（FleetManagementSystem)
ITS：智能交通系统（IntelligentTransportationSystem)R曰：路侧检查（RoadsideInspection)
V21：车与基础设施通信（Vehicle-to-Infrastructure)V2V：车与车通信（Vehicle-to-Vehicle)
5网联车辆通用信息
5.1阿联车辆概念
5.1.1网联车辆指能够实现车辆功能的所有技术部件，也包括外部接口，如图1和图2所示。图1表示整体概念，图2表示代表性接口，包括：
一一物理连接接口；
一一网络服务接口；
一一无线实时通信接口；
其他接口，此类接口无标准化需求。
5.1.2由于道路车辆是网联车辆的一部分，因此道路车辆的一些物理连接接口（见图2）同时也是网联车辆的外部接口。
5.1.3网络服务接口是网联车辆的代表性外部接口之一，如图2所示。网络服务通过网络服务接口实现网联车辆与服务器的交互。服务提供商管理的服务器不属于网联车辆，服务提供商可以通过该服务器与网联车辆进行通信（见图3）。
5.2网联车辆的设计限制
网联车辆的远程访问功能不应危及人员或货物（车辆内部或外部）的基本安全以及车辆在其整个生命周期中的安全（包括信息安全）。
附录B
（资料性）网联车辆预期应用领域
B.1网联车辆不是为解决特定需求（如远程诊断）而产生的特殊技术解决方案，这项技术将常规的道路车辆扩展至包括车外系统，这项技术可应用于所有需要车辆互联的领域。
B.2网联车辆有以下六个主要预期应用领域（见图B.1)。
车辆维修升级领域。此领域的典型用例集是远程诊断、预测、修理、在线软件升级，此领域的特点是受国家或地方法规的影响很大。
一一一车辆检查领域。此领域的典型用例集是远程RSI，此领域的特点是检查操作者受地方管理机构监管。
驾驶任务支持领域。此领域的典型用例集包括V2V、V2I以及支撑驾驶辅助和自动驾驶等的通信，此领域的特点是需要用到低时延的通信。
一一运输管理领域。此领域的典型用例集是远程FMS，此领域的特点是将车队作为一个整体。一一一制造与销售领域。此领域的典型用例集是制造过程中的车辆远程诊断，此领域的特点是车辆
的所有者仍是车辆制造厂。
一一非汽车领域。此领域的典型用例集是信息娱乐、车辆保险、远程驾驶员及驾驶调查，此领域的特点是用例种类繁多，通常源于汽车产业之外。
B.3应对如此多的需求，用例集的良好描述对于开发基于网联车辆的技术解决方案至关重要。
附录C
（资料性）网联车辆方法论标准
C.1GB/T系列文件的内容
GB/T系列文件包含了适用于网联车辆的各种通用规范。这些文件不包含任何具体技术规范。
本文件为GB/T的第1部分，包括了关于网联车辆的基本定义、概念、实例以及相关标准。
GB/T.2用于指导网联车辆的设计开发，C.2.2介绍了其内容。
C.2GB/T.2
C.2.1GB/T.2的目的
GB/T.2的目的是指导网联车辆及其外部接口的设计（物理、文档、支持等），以限制与安全性、防护性和法规符合性相关的风险，特别是涉及公平竞争时。
由于大多数车辆制造厂已经实施了有效的质量管理体系（例如，已被认证符合ISO或同等系列标准）。因此，可通过以下步骤确保网联车辆的设计质量：
一一车辆制造厂基于GB/T.2中的规则和基本原则，建立自己的方法和流程来设计网联车辆，从而满足目标销售市场的法律要求；车辆制造厂采用由其质量管理体系强制要求的方法和流程。
GB/T.2旨在指导网联车辆的设计流程，并不涉及关于从网联车辆制造厂处获得信息以开发新业务的流程。但为了降低风险，建议所有选择应用GB/T.2的各方均可采用这些流程。
C.2.2GB/T.2的内容
GB/T.2规定了一组通用的规则和基本原则，每个车辆制造厂都可按照规则和基本原则衍生出自己的方法或流程来设计网联车辆。
规定了一个通用的规则和基本原则的体系，各车辆制造厂可据此制定出自己的应用方法或流程。
适用于网联车辆的制造设计流程。在网联车辆设计阶段，可以存在非本文件范围内的流程。GB/T.2由3部分组成（见图C.1):
需求方使用的指南（模板〉，用于完整地描述网联车辆的使用需求（适当的用例、场景与功能需求
一一车辆制造厂使用的指南（规则和基本原则），用于避免在设计流程中遗漏设计步骤；
车辆制造厂使用的指南（模板），用于向需求方展示设计的技术成果。
GB/T.2可能不涉及网联车辆的完整设计流程（例如，标准中与竞争相关的基本原则不涉及传动装置的设计，而网联车辆制造厂会根据适用的法律规定，决定在什么情况下不应用此标准，而在其他情况下应用此标准）。
第三方使用GB/T.2中“技术需求模板”来表达技术需求，需求的表达过程GB/T.2未标准化。车辆制造厂根据GB/T.2执行设计并根据“技术响应模板”来表达设计的技术成果。
GB/T.2未对技术响应过程进行标准化。在不能响应需求的情况下，需求方尽管可能要采取商业或法律措施，但仍可以采用如下措施：
一一与车辆制造厂签订协议，以获取能够优化解决方案的材料和信息；要求对新的用例集进行标准化；
一一通过适当的法规变更使需求得到满足。
GB/T.2既未引用任何特定的国家或地区法规，也未引用特定技术设计规则或技术解决方案（硬件或软件〉的任何标准。
联系电话：